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Abstract 

A  framework  for  the  flexible  and  conservative  modification  of  plans  enables  a  planner  to 
modify  its  plans  in  response  to  incremental  changes  in  their  specifications,  to  reuse  its  existing 
plans  in  new  problem  situations,  and  to  efficiently  replan  in  response  to  execution  time  failures. 
We  present  a  theory  of  plan  modification  applicable  to  hierarchical  nonlinear  planning.  Our 
theory  utilizes  the  validation  structure  of  stor^  plans  to  yield  a  flexible  and  conservative  plan 
modification  framework.  The  validation  structure,  which  constitutes  a  hierarchical  explanation 
of  correctness  of  the  plan  with  respect  to  the  planner’s  own  knowledge  of  the  domain,  is  anno¬ 
tated  on  the  plan  as  a  by-product  of  initial  planning.  Plan  modification  is  formalized  as  a  pro¬ 
cess  of  removing  inconsistencies  in  the  valid^on  structure  of  a  plan  when  it  is  being  reused  in 
a  new  (changed)  planning  situatioa  The  repair  of  these  inconsistencies  involves  removing 
unnecessary  parts  of  the  plan  and  adding  new  non-primitive  tasks  to  the  plan  to  establish  miss¬ 
ing  or  failing  validations.  The  resultant  partially  reduced  plan  (with  a  consistent  validation 
structure)  is  sent  to  the  planner  for  complete  reductioa  We  discuss  the  develc^ent  of  this 
theory  in  the  PRIAR  system,  present  an  empirical  evaluation  of  this  theory,  and  characterize  its 
completeness,  coverage,  efficiency  and  limiutions. 
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1.  Introduction 

The  ability  to  incrementally  modify  existing  plan;,  to  make  them  conform  to  the  constraints  of 
a  new  or  changed  planning  situation  is  very  useful  in  plan  reuse  (reusing  existing  plans  to 
solve  new  planning  p'’’>blcms),  replanning  (modifying  a  current  plan  in  response  to  executing 
time  failures),  and  incremental  planning  (updating  a  plan  in  response  to  evolving  specifications 
during  interactive  planning).  Two  imponant  desiderata  for  the  plan  modification  capability  are 
flexibility  and  conservatism.  Flexibility  is  the  ability  to  modify  a  plan  to  handle  a  wide  variety 
of  changes  in  the  specification.  <^onservatism  is  the  ability  to  minimally  change  the  existing 
plan  to  make  it  fit  to  the  new  problem  situation.  The  former  is  required  for  effective  coverage 
of  modification,  while  the  latter  is  needed  to  ensure  efficiency. 

While  the  value  of  plan  modification  has  been  acknowledged  early  in  plaiming  research 
[6,9],  the  strategies  developed  were  inflexible,  in  that  they  could  reuse  or  modify  a  given  plan 
in  only  a  limited  number  of  situations,  and  could  deal  with  only  a  limited  variety  of  applicabil¬ 
ity  failures.  There  was  no  general  framework  for  conservatively  modifying  an  existing  plan  to 
fit  it  to  the  constraints  of  a  new  problem  situation.  A  major  shortcoming  with  these 
approaches  was  that  the  stored  plans  did  not  represent  enough  information  about  the  internal 
dependencies  of  the  plan  to  permit  flexible  modificatioa  For  example,  reuse  based  on  macro¬ 
operators  [6]  built  from  sequences  of  primitive  plan  steps  was  unable  to  modify  intermediate 
steps  of  the  macro-operators  as  the  macro-operators  did  not  represent  the  intermediate  deci¬ 
sions  and  dependencies  corresponding  to  their  internal  steps.  Even  in  cases  where  the  need  for 
the  dependency  information  was  recognized  (e.g.  [5, 34)),  a  systematic  represenudon  and  utili- 
zadon  of  such  structures  m  plan  reuse  and  modificadon  was  not  attempted. 

We  present  a  theory  of  plan  modificadon  that  allows  flexible  arxl  conservative 
modification  of  plans  generated  by  a  hierarchical  ronlinear  planner.  Hierarchical  planning  is  a 
prominent  method  of  abstraction  and  least-commitment  in  domain-independent  planning  [4], 
Our  theory  of  plan  modification  proposes  validation  structure  as  a  way  of  representing  the 
internal  dependencies  of  a  hierarchical  plan  and  provides  algorithms  for  armotating  the  valida¬ 
tion  structure  on  the  plans  during  plan  generation.  It  systematically  explores  the  utility  of  the 
armotated  validation  structure  in  guiding  and  controlling  all  the  processes  involved  in  flexible 
plan  reuse  arxl  modification.  The  PRIAR  reuse  system  [IS,  16, 17, 14, 13, 12]  is  our  implemen¬ 
tation  of  this  theory.  This  paper  presents  the  plan  modification  framework  used  in  priar  and 
evaluates  its  performance,  completeness,  coverage,  efficiency  and  limitations. 

1.1.  Overview  of  the  PRIAR  Plan  Modification  Theory 

The  plan  modification  problem  that  is  addressed  in  priar  is  the  following:  Given  (i)  a 
planning  problem  P”  (specified  by  a  partial  description  of  the  initial  state  /”  and  goal  state 
G”).  (ii)  an  existing  plan  /?'’  (generated  by  a  hierarchical  nonlinear  planner),  and  the 
corresponding  planning  problem  P®,  Produce  a  plan  for  P"  by  minimally  modifying  P®.  Rg- 
ure  1  shows  the  schematic  overview  of  the  PRIAR  plan  modification  framework. 
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(2)  Annotation  Verification:  The  inconsistencies  in  the  validation  stnicturc  of  /?'  are  located, 
and  appropriate  repairs  are  suggested.  The  repairs  include  removing  parts  of  /?'  that  arc 
unnecessary  and  adding  non-primitive  tasks  (called  refit  tasL';)  to  establish  any  required  new 
validations.  The  resulting  annotation-verified  plan  will  have  a  consistent  validation  struc¬ 
ture  but  is  typically  only  panially  reduced.  It  consists  of  all  the  applicable  pans  of  R‘  and 
any  newly  introduced  refit  tasks. 

(3)  Refitting:  The  refit  tasks  specified  during  the  annotation  verification  phase  constitute  sub- 
plarming  problems  for  the  hierarchical  planner.  The  refuting  process  involves  reducing  them 
with  the  help  of  the  planner.  Conservatism  is  ensured  during  this  process  through  the  use  of 
a  heuristic  control  strategy  which  minimizes  the  disturbance  to  the  applicable  parts  of  /?"  by 
estimating  the  disturbance  caused  to  its  validation  structure. 

Computational  savings  stem  from  the  fact  that  the  complexity  of  solving  the  sub-planning 
problems  during  refitting  is  much  less  than  the  complexity  of  solving  the  entire  planning  prob¬ 
lem  from  scratch.  This  is  supported  by  the  results  of  the  empirical  studies  in  blocks  world, 
which  showed  that  plan  modification  provides  20-98%  savings  (corresponding  to  speedup  fac¬ 
tors  of  1.5  to  50)  over  pure  generative  planning,  with  the  highest  gains  shown  for  the  most 
complex  problems  tested  (the  details  of  these  studies  are  provided  in  section  4.1). 

1.2.  Comparison  to  Previous  Work 

Here  we  will  briefly  summarize  some  broad  distinctions  between  our  theory,  and  the  previous 
approaches  to  plan  modification;  a  more  detailed  discussion  of  related  work  appe^  in  section 
6  and  in  [13]. 

Representations  of  plan  internal  dependency  structure  have  been  used  by  several  planners 
previously  to  guide  plan  modification  (e.g.,  the  triangle  tables  and  the  macro  operators  of  [6] 
and  [11];  the  decision  graphs  of  [9]  and  [5];  the  plan  rationale  representation  of  [34]).  How¬ 
ever,  our  work  is  the  first  to  systematically  charaaerize  the  nature  of  such  dependency  stnic- 
tures  and  their  role  in  plan  modification.  It  subsumes  and  formalizes  the  previous  approaches, 
provides  a  better  coverage  of  applicability  failures,  and  allows  the  reuse  of  a  plan  in  a  larger 
variety  of  new  planning  situations.  Unlike  the  previous  approaches,  it  also  explicitly  focuses 
on  the  flexibility  and  conservatism  of  the  plan  modification.  The  modification  is  fully 
integrated  with  the  generative  planning,  and  aims  to  teduce  the  average  case  cost  of  producing 
correct  plans.  In  this  sense,  PRIAR’s  strategies  are  complementary  to  the  plan  debugging  stra¬ 
tegies  proposed  in  GORDIUS  [27]  and  CHEF  [8],  which  use  an  explanation  of  correctness  of  the 
plan  with  respect  to  an  external  (deeper)  domain  model — generated  through  a  causal  simulation 
of  the  plan  to  guide  the  debugging  of  the  plan — to  compensate  for  the  inadequacies  of  the 
planner’s  own  domain  model.  Similarly,  PRIAR’s  validation  structure  based  approach  to  plan 
modification  stands  in  contrast  to  tq)proaches  which  rely  on  domain  dependent  heuristic 
modification  of  the  plan  (e.g.  [8, 1,22]).  Our  approach  of  grounding  plan  modification  on  vali¬ 
dation  structure  guarantees  the  correctness  of  the  modification  with  respect  to  planner’s  domain 
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model  and  reduces  the  need  for  a  costly  modify-test-debug  approach. 

1.3.  Organization  of  the  Paper 

The  rest  of  this  section  introduces  some  preliminary  notation  and  tcmiinology  used  throughout 
the  paper.  Sccti  tn  2  presents  the  notion  of  plan  validation  structure,  explains  the  motivation 
behind  remembering  it  along  with  each  generated  plan,  and  develops  a  scheme  for  annotating 
the  plans.  Section  3  develops  the  basic  modification  processes,  and  explains  how  they  utilize 
the  plan  validation  structure.  In  particular,  it  provides  the  details  of  the  mapping,  annotation 
verification  and  refining  processes  and  presents  an  example  of  plan  modification  in  this  frame¬ 
work.  It  also  includes  a  brief  discussion  of  the  control  strategics  for  guiding  refitting  and 
retrieval.  Section  4  contains  an  empirical  and  theoretical  analysis  of  the  PRIAr  plan 
modification  theory.  It  summarizes  the  results  of  the  empirical  evaluation  experiments  con¬ 
ducted  on  the  implemented  system,  and  discusses  the  completeness,  coverage,  flexibility  and 
efficiency  of  the  modification  framework.  Section  5  contains  a  detailed  discussion  of  related 
work  and  section  6  summarizes  the  research.  Appendix  A  contains  an  annotated  trace  of  the 
PRIAR  system  solving  a  problem  and  ARxndix  B  contains  the  specification  of  the  domain  used 
in  the  empirical  evaluation. 

1.4.  Preliminaries,  Notation  and  Terminology 

This  paper  develops  a  theory  of  plan  modification  in  the  context  of  hierarchical  nonlinear  plan¬ 
ning.  Hierarchical  nonlinear  planning  (known  also  as  hierarchical  planning)  is  a  prominent 
method  of  abstraction  and  least  commitment  in  domain  independent  planning.  A  good  intro¬ 
duction  to  this  methodology  can  be  found  in  [4].  Some  well  known  hierarchical  planners 
include  NOAH  [25],  NONUN  [30]  and  SIPE  [33].  For  a  review  of  these  and  other  previous 
approaches  to  planning,  sec  [10], 

In  hierarchical  planning,  a  partial  plan  is  represented  as  a  task  network  consisting  of  high 
level  tasks  to  be  carried  out.  A  task  network  is  a  set  of  tasks  with  partial  chronological  order¬ 
ing  relations  among  the  tasks.  Planning  involves  reducing  these  high  level  tasks  with  the  help 
of  predefined  “task  reduction  schemas,”  to  successively  more  concrete  subtasks.  The  task 
reduction  schemas  are  given  to  the  planner  a  priori  as  part  of  the  domain  specification.  The 
collection  of  task  tietworks,  at  increasing  levels  of  detail  showing  the  development  of  the  plan, 
is  called  the  “hierarchical  task  network”  or  “HTN”  of  the  plan.  Planning  is  considered  com¬ 
plete  when  the  all  the  leaf  nodes  of  tlie  HTN  are  either  primitive  tasks  (tasks  that  cannot  be 
decomposed  any  further)  or  phantom  goals  (tasks  that  are  achieved  as  side-effects  of  some 
other  tasks).  The  entire  tree  structure  in  Figure  2  shows  the  hierarchical  plan  for  a  simple 
blocks  world  planning  problem.  In  the  following,  we  provide  formal  definitions  of  some  of 
these  notions,  to  facilitate  the  development  in  the  rest  of  the  paper. 

§1.1.  Partial  Plans  and  Task  networks:  A  partial  plan  P  is  represented  as  a  task  netwoik 
and  can  be  formalized  [37]  as  a  3-tuple  (T ,0  JT),  where  T  is  a  set  of  tasks,  O  defines  a  partial 
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orJcring  among  elements  of  T,  and  FI  is  a  set  of  conditions  along  with  specifications  about 
where  those  conditions  must  hold.  Each  task  T  has  a  set  of  applicability  conditions,  denoted 
by  condinons{T).  and  a  set  of  expected  effects,  denoted  by  effects(J),  where  each  set  con- 
sisls  of  literals  in  first  order  predicate  calculus.  Elements  of  FI  arc  called  protection  intervals 
[4],  and  arc  represented  by  3-tuplcs  (E.rj.ri).  where  f,,r2  e  T,  E  c,  effectsUx)  and  £  has  to 
necessarily  persist  up  to  t^. 

§1.2.  Schemas  and  Task  Reduction:  A  task  reduction  schema  S  caii  itself  be  formalized  as  a 
mini  task  networl,  template  that  can  be  used  to  replace  some  task  r  s  T  of  the  plan  P ,  when 
certain  applicability  conditions  of  the  schema  are  satisfied.  Satisfying  the  applicability  condi¬ 
tions  this  way  involves  adding  new  protection  intervals  to  the  resultant  plan.  Thus  when  the 
set  of  applicability  conditions  [Cf]  of  an  mstance  S,  of  a  task  reduction  schema  5  can  be 
satisfied  at  a  task  /  in  a  partial  plan  P,  then  t  can  be  reduced  with  S,  .  The  reduction,  denoted 
by  S,(f),  is  another  task  network  The  task  t  will  be  linked  by  a  parent  relation  to 

each  task  of  7,*.  The  plan  P‘  resulting  from  this  task  reduction  is  constructed  by  incorporat¬ 
ing  Silt)  into  P .  During  this  incorporation  step,  some  harmful  interactions  may  develop  due 
to  the  violation  of  established  protection  intervals  of  P.  The  planner  handles  these  harmful 
interactions  either  by  posting  additional  partial  ordering  relations,  or  by  backtracking  over 
previous  planning  decisions.  When  the  planner  is  successful  in  incorporating  5,  (r)  into  P 
and  resolving  all  the  harmful  interactions,  the  resultant  plan,  P'  can  be  represented  by  the  task 
network  /’':(rtJ7,-{r},  OXJOjKJOi,  11'),  where: 

(1)  O'  is  computed  by  appropriately  redirecting  the  ordering  relations  involving  the  reduced 
task  f  to  its  cfildrcn 

(2)  Oj  are  the  ordering  relations  introduced  during  the  interaction  resolution  false 

(3)  Finally,  the  protection  intervals  fl'  is  computed  by  (i)  combining  11  and  n,,  (/i)  adding 
any  protection  intervals  that  were  newly  established  to  support  the  applicability  conditions 
of  the  schema  instance  5,-  and  (Hi)  appropriately  redirecting  the  protection  intervals 
involving  the  reduced  task  t  to  its  childrea 

During  the  redirection  in  the  last  step,  the  planner  converts  any  protection  interval 
(£,11,12)  s  n  where  ii=i  to  (C,/,ft,/2).  and  converts  any  protecdon  intervals  where  12=1  to 
(C,ii,f„)  (where  are  appropriate  tasks  belonging  to  7,).  The  various  implemented 

planners  follow  different  conventions  about  how  the  appropriate  i,i,  and  t„  are  computed.  For 
example,  irrespective  of  the  protected  condition  £,  NONUN  [29j  makes  r,*  to  be  ij,, ,  and  1^  to 
be  where  tb,g  and  are  the  beginning  and  ending  tasks  of  7,  (i.e.,  no  task  of  7,  pre¬ 
cedes  tbeg  or  follows  )  respectively.  Other  conventions  might  look  at  the  effects  and 

'  When  the  task  1  is  of  the  form  achieve(C),  and  C  can  be  achieved  directly  by  using  the  eh'ects  of  some 
other  task  fc  €  7,  then,  I  becomes  a  phantom  task  and  its  reduction  becomes  ({plum'om(C)),0,0).  A  new  pro¬ 
tection  interval  (C  jfj)  will  be  added  to  the  resultant  plan. 


s' 
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condiilons  of  tasks  Ivlonging  to  7^  to  decide  and  For  the  purposes  of  this  paper,  either 
of  llicse  conventions  is  admissible. 

§  IJ.  Completed  Plan:  A  task  network  is  said  to  represent  a  completed  plan  when  none  of  its 
tasks  have  to  bo  reduced  further.  Tlic  planner  cannot  reduce  certain  distinguished  tasks  of  the 
domain  called  prinAiive  tasks.  (It  is  assumed  that  the  planner  already  knows  how  to  execute 
such  tasks.)  Further,  if  all  the  required  effects  of  a  task  arc  already  true  in  a  given  partial  plan. 
Lhen  titat  task  docs  not  have  to  be  reduced  any  further  (such  tasks  are  called  phantom  goals 
[41). 

§  1.4,  Hierarchical  Task  Network  (HTN):  The  hierarchical  development  of  a  plan 
7:(r.(9,n)  is  captured  by  its  hierarchical  task  network  (abbreviated  as  HTN).  HTN(7)  is  a  3- 
tuple  (7:(7.0.n),  7*/)),  where  7*  is  the  union  of  set  of  ta.sks  in  7  and  all  their  ancestors, 
and  D  represents  the  parent-child  relations  between  the  elements  of  7* .  The  set  n  is  the  set  of 
protection  intervals  associated  with  HTN(P).  (For  convenience,  we  shall  abbreviate  HTN(/^)  to 
HTN,  where  Uic  reference  to  P  is  unambiguous,  and  also  refer  to  the  members  of  7*  as  the 
nodes  of  HTN.)  The  HTN  of  a  plan  thus  captures  the  development  of  that  plan  in  terms  of  the 
corresponding  task  reductions.  We  shall  refer  to  the  number  of  leaf  nodes  in  the  HTN,  171  as 
the  length  of  the  corresponding  plan,  and  denote  it  by  Np . 

For  the  sake  of  uniformity,  we  shall  assume  that  there  arc  two  special  primitive  nodes  n/ 
and  kq  in  the  HTN  corresponding  to  the  input  state  and  the  goal  state  of  the  planning  problem, 
such  that  effectsinj)  comprise  the  facts  true  in  the  initial  specification  of  the  problem,  and 
conditions {hq)  contain  the  goals  of  the  problem.  The  notation  “/tj  <  /I2”  (where  and  rt2 
arc  nodes  of  HTN)  is  used  to  indicate  tliai  is  ordered  to  precede  ni  in  the  partially  ordercred 
plan  represented  by  the  HTN  (i.e.,  /ii  €  predecessor*  where  the  predecessor  relations 
enforce  the  partial  ordering  among  the  nodes  of  the  HTN).  Similarly,  “rti  >  rt2”  denotes  that 
Hi  is  ordered  xo  follow  ni*  and  denotes  that  there  is  no  ordering  relation  between 

the  two  nodes  (ni  is  parallel  to  Tlxj  set  consisting  of  a  node  n  and  all  its  descendents  in 
the  HTN  is  defined  as  the  sub-reduction  of  n,  and  is  denoted  by  R(n).  Following  [4,30],  we 
also  distinguish  two  types  of  plan  applicability  conditions:  the  preconditions  (such  as  Clear  (A) 
in  the  blocks  world)  which  the  planner  can  achieve,  and  the  filter  conditions  (such  as 
Block  (A))  which  the  planner  cannot  achieve.  We  shall  use  the  notation  “F  I—  /”  to  indicate 

that  /  deductively  follows  from  the  set  of  facts  in  F,  Finally,  the  modal  operators  ”  and 

denote  necessary  and  possible  truth  of  an  assertion. 

2.  Validation  Structure  and  Annotations 

Here  we  formally  develop  the  notion  of  the  validation  structure  of  a  plan  as  an  explicit 
representation  of  the  internal  dependencies  of  a  plan,  and  provide  motivation  for  remembering 
such  structures  along  with  the  stored  plan.  We  will  begin  the  discussion  by  defining  our 
notion  of  validation,  present  a  scheme  for  representing  the  validation  structure  locally  as 
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annotations  on  individual  nodes  of  a  HTN,  and  finally  discuss  algorithms  for  efficient  computa¬ 
tion  of  these  node  validations. 

2.1.  Validation  Structure 

§2.1.  Validation:  A  validation  v  is  a  4-tuple  (E,nj,C,  nj),  where  n,  and  are  leaf  nodes 
belonging  to  the  HTN,  and  the  effect  E  of  node  n,  (called  the  source)  is  used  to  satisfy  the 
applicability  condition  C  of  node  (called  the  destination).  C  and  E  are  referred  to  as  the 
supported  condition  and  the  supporting  effect  respectively  of  the  validation.  As  a  necessary 
condition  for  the  existence  of  the  validation  v,  the  partial  ordering  among  the  tasks  in  HTN 
must  satisfy  tlie  relation  n,  <nj .  The  type  of  a  validation  is  defined  as  the  type  of  the  applica¬ 
bility  condition  that  the  validation  supports  (one  of  filter  condition,  precondition,  phantom 
goat).  Notice  that  every  validation  v:  (E,  n,,  C .  Kf)  corresponds  to  a  protection  interval 
(E  ,n^  ,nj)  €  n  of  the  HTN  (that  is,  the  effect  E  of  i.  ode  /i,  is  protected  from  node  n,  to  node 
n^).  This  correspondence  implies  that  there  will  be  a  hnite  set  of  validations  corresponding  to 
a  given  HTN  representing  the  development  of  a  plan:  we  shall  call  this  set  V.  Of  5  is  the  max¬ 
imum  number  of  applicability  conditions  for  any  action  in  the  domain,  then  IVl  £  ^p,  where 
Np  is  the  length  of  the  plan  as  defined  above  [13].) 

Figure  2  shows  the  validation  structure  of  the  i  m  for  solving  a  block  stacking  problem 
,3BS  (also  shown  in  the  figure).  Validations  are  represented  graphically  as  links  between  the 
effect  of  the  source  noue  and  the  condition  of  the  destination  node.  (For  the  sake  of  exposi¬ 
tion.  validations  supporting  conditions  of  the  type  Block{?x)  have  not  been  shown  in  the 
figure.)  As  an  example,  (O/i (B  ,C),n  15,0« (B ,C),nc)  is  a  validation  belonging  to  this  plan 
since  On(B,C)  is  required  at  the  goal  state  nc,  and  is  provided  by  the  effect  On(B,C)  of 
node  n  15. 

The  level  of  a  validation  is  defined  as  the  reduction  level  at  which  it  was  first  introduced 
into  the  HTN  (see  [13]  for  the  formalization  of  this  notion).  For  example,  in  Figure  2,  the  vali¬ 
dation  {Block(A),n,^lock(,A).ni^  considered  to  be  of  a  higher  level  than  the  validation 
(pn(A, Table), ni,On(A,Table),n\^,  since  the  former  is  introduced  imo  the  HTN  to  facilitate 
the  reduction  of  task  n^  while  the  latter  is  introduced  during  the  reduction  of  task  n^.  A  useful 
characteristic  of  hierarchical  plaruiing  is  that  its  domain  schemas  are  written  in  such  a  way  that 
the  more  important  validations  are  established  at  higher  levels,  while  the  establishment  of  less 
important  validations  is  delegated  to  lower  levels.  Thus,  the  level  at  which  a  validation  is  first 
introduced  into  an  HTN  can  be  taken  to  be  predictive  of  the  importance  of  that  validation,  and 

the  effort  required  to  (re)establish  it.*  The  validation  levels  can  be  pre-computed  efficiently  at 
the  time  of  annotation. 


*  We  assume  that  domain  schemas  having  this  type  of  abstraction  property  are  supplied/encoded  by  the  user  in 
the  first  place.  What  we  are  doing  here  is  to  exploit  the  notion  of  importance  implicit  in  that  abstraction. 


On(A.B)&On(B,C) 


I 
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Figure  2.  Validation  Structure  of  3BS  Plan 


As  the  specification  cf  the  plan  changes  or  as  the  planner  makes  new  planning  decisions, 
the  dependencies  of  the  plan  as  represented  in  its  validation  structure  get  affected.  The  notions 
of  coriai.':?f.ncy  and  incop'’-  ►-ncies,  developed  below,  capture  the  effects  of  such  changes  on  the 
plan  vail.'  *ion  structure. 

§2,2.  Inconsistencies  and  Consistency  of  Validation  Structure:  A  HTN  is  said  to  have  a 
consistent  validation  structure  if  it  does  not  have  any  unnecessary,  missing  or  failing  valida¬ 
tions.  The  unnecessary,  missing  or  failing  validations  in  a  HTN  will  be  referred  to  as 
ir consistencies  in  its  validation  stnicture. 

•  \  validation  v  :(E  ,n,  ,C  ,nf)  is  considered  a  failing  validation  when  the  corresponding  pro¬ 
tection  interval  is  undone.  More  formally,  v  is  a  failing  validation  iff: 

[  effects(n,)W-  E  JV  [  ^(n,<n<rtd)  A  effects{n')  h-  -£  ] 

Thus,  for  every  non-failing  validation  v  :iE  ,n,  ,C  ,nf)  of  a  HTN,  the  effects  of  n,  should  entail 
£,  and  £  should  necessarily  persist  from  n,  to  n^. 

•  A  validation  v:  (E,  n^,  C ,  nf)  is  considered  an  unnecessary  validation  if  it  is  not  required 
to  support  the  rondition  C  at  node  nj.  This  could  happen  either  because  n^  is  no  longer  a  part 
of  -he  HTN  or  because  it  no  longer  requires  the  condition  C. 

•  There  is  a  missing  validation  corresponding  to  a  condition,  trade  pair  If'jn')  of  the  HTN  iff 

3  v:  n,,  C,  «d)  s.t.  C=C'f\  n^=n*  (i.e.,  the  condition  C'  is  not  supported  by  any  valida¬ 

tion). 

Let  us  consider  the  example  of  the  3BS  plan  shown  in  Figure  2.  If  the  specification  of 
this  plan  is  changed  such  that  On  (AM)  is  no  longer  a  goal,  then  (pn(A  ,B).ni(„On(A  ,B),nG) 
will  be  an  unnecessary  validation.  Further,  if  the  new  specification  contains  a  goal  On  (A  J) ), 
then  since  there  is  no  validation  supporting  the  condition  node  pair  (pn(A  J)),na).  there  is  a 
missing  validation  corresponding  to  this  pair,  finally,  if  we  suppose  that  the  new  Reification 
contains  On(D,A)  in  its  initial  state,  then  the  validation  (flear(A),ni, Clear (,A),ni)  will  be 
failing,  as  effecting)  H-  Clear(A). 

From  these  definitions,  it  should  be  clear  that  in  a  HTN  with  a  consistent  validation  struc¬ 
ture,  each  applicability  condition  of  a  node  (including  each  goal  of  )  will  have  a  non-failing 
validation  supporting  it  (A  completely  reduced  HTN  with  a  consistent  validation  structure  con¬ 
stitutes  a  valid  executable  plan.) 

2.2.  Annotating  Validation  Structures 

Having  developed  the  notion  of  validation  in  a  plan,  our  next  concern  is  representing  the  vali¬ 
dation  structure  of  the  plan  locally  as  annotations  on  individual  nodes  of  a  HTN.  The  intent  is 
to  let  these  annotations  encapsulate  the  role  played  by  the  sub-reduction  below  that  node  in  the 
validation  structure  of  the  overall  plan,  so  that  they  can  help  in  efficiently  gauging  the  effect  of 
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any  modification  at  that  node  on  the  overall  validation  structure  of  the  plan.  We  achieve  this  as 
follows:  For  each  node  n  e  HTN  we  define  the  notions  of  (<)  e-conditions(«),  which  are  the 
externally  useful  validations  supplied  by  the  nodes  belonging  to  /?  (n )  (the  sub-reduction  below 
n)  (iV)  e-preconditions(n).  which  are  the  externally  established  validations  that  are  consumed 
by  nodes  of  /?(n),  and  (Hi)  p-conditions(n),  which  arc  the  external  validations  of  the  plan  that 
arc  required  to  persist  over  the  nodes  of  R  (n ). 

§23.  £-Conditions  (External  Effect  Conditions):  The  e -conditions  of  a  node  n  correspond 
to  the  validations  supported  by  the  effects  of  any  node  of  R(n)  which  arc  used  to  satisfy  appli¬ 
cability  conditions  of  the  nodes  that  lie  outside  the  sub-reduction.  Thus. 

e -conditions (n)  -  {v,:  (£,  n,,  C,  «.<)|v,€V;  n,e£(n);  n^dRfn)  ) 

For  example,  the  e-conditions  of  the  node  n^  in  the  HTN  of  Figure  2  contain  just  the  validation 
(pn(A,B),  nj6>  On(A.B),  na)  since  that  is  the  only  effect  of  Rin^)  which  is  used  outside  of 
Rin^).  The  e-conditions  provide  a  way  of  stating  the  externally  useful  effects  of  a  sub¬ 
reduction.  They  can  be  used  to  decide  when  a  sub-reduction  is  no  longer  necessary,  or  how  a 
change  in  its  effects  will  affect  the  validation  structure  of  the  parts  of  the  plan  outside  the  sub¬ 
reduction. 

From  the  definition,  the  following  relations  between  the  e-conditions  of  a  node  and  the 
e-conditions  of  its  children  follow: 

(1)  If  n  is  a  leaf  node,  then  R(n)=  {«)  and  the  e -conditions  of  n  will  simply  be  all  the 
validations  of  HTN  whose  source  is  n . 

(2)  If  n  is  not  a  leaf  node,  and  nc  €  children (n),  and  Vg:(E ,nf,C .n^)  is  an  e-condition  of 
rif,  then  v,  will  also  be  an  e-condition  of  n  as  long  as  nj^R(n)  (since  /?(n<.)  c  R(n). 
[n,  €  /?(/»£>]  =*  [rt,  e  /?(n)]). 

(3)  If  vJ^E,nj,C ,na)  is  an  e-condition  of  n,  then  e  children (n)  such  that  v  is  an  e- 
condition  of  n,..  This  follows  from  the  fact  that  if  n^^R(n)  then  e  childrenfn) , 
nj  d  R(nc),  and  that  if  n,  e  R(n),  then  BUg  e  children (n)  such  that  n,  €  R(nc). 

These  three  relations  allow  priar  to  first  compute  the  e-conditions  of  all  the  leaf  nodes  of  the 
HTN,  and  then  compute  the  e-conditions  of  the  non-leaf  nodes  from  the  e-conditions  of  their 
children. 

§2.4.  £ -Preconditions  (External  Pretonditi«ns):  The  e -preconditions  of  a  node  n 
correspond  to  the  validations  supporting  the  applioibility  conditions  of  any  node  of  R(n)  that 
are  satisfied  by  the  effects  of  the  nodes  that  lie  outside  of  R(n).  Thus, 

e -preconditions (n)=  {v,:  ^£,  C,  n^)|v,€V;  «^e/?(r):  nj4R(n)  } 

For  example,  the  e-preconditions  of  the  node  713  in  the  HTN  of  Figure  2  will  iric’ude  the  valida¬ 
tions  (Clear(A),  «/,  Clear(A),  n-f)  and  (ClearfB),  n/,  ClearfB),  ng).  The  e-preconditions  of 
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a  node  can  be  used  to  locate  the  parts  of  rest  of  the  plan  that  will  become  unnecessary  or 
redundant,  if  tlie  sub-reduction  below  that  node  is  changed. 

From  the  definition,  the  following  relations  between  the  e-preconditions  of  a  node  and  the 
e-preconditions  of  its  children  follow: 

(1)  If  n  is  a  leaf  node,  then  R(n)=  {« )  and  the  e -preconditions  of  n  will  simply  be  all  the 
validations  of  HTN  whose  destination  is  n . 

(2)  If  n  is  not  a  leaf  node,  and  e  children(n),  and  is  an  e-precondition  of 

ric,  then  will  also  be  an  e-prccondition  of  «  as  long  as  /?(n)  (since  /?(/ic)c  £(«). 
rtj  €  R{n)). 

(3)  If  v:{E,nj,C  jtd)  is  an  e-precondition  of  n.  then  e  children (n)  such  that  v  is  an  e- 
prccondition  of  n,..  This  follows  from  the  fact  that  if  /?(«)  then  vn^  e  children{n) 
n,dRin^)  and  that  if  e  R(n),  then  3 e  children (r.)  such  that  nj  e  R{nc). 

These  three  relations  allow  priar  to  first  compute  the  e-preconditions  of  all  leaf  nodes  of  the 
HTN,  and  then  compute  the  e-preconditions  of  the  non-leaf  nodes  from  the  e-preconditions  of 
their  children. 

From  the  definitions  of  e-conditions  and  e-preconditions,  it  should  be  clear  that  they  form 
the  forward  and  backward  validation  dependency  links  in  the  HTN.  For  the  sake  of  uniformity, 
the  set  of  validations  of  type  ,«(;),  (where  G  is  a  goal  of  the  plan)  are  considered  e- 

preconditions  of  the  goal  node  nc.  Similarly,  the  set  of  validations  (/,n/,C,n,),  (where  /  is  a 
fact  that  is  true  in  the  input  state  of  the  plan)  are  considered  e-conditions  of  the  input  node  n/. 

§2,5.  P -Conditions  (Persistence  Conditions):  P-conditions  of  a  node  n  correspond  to  the 
protection  intervals  of  the  HTN  that  are  external  to  R  (n),  and  have  to  persist  over  some  part  of 
Rin)  for  the  rest  of  the  plan  to  have  a  consistent  validation  structure.  We  define  them  in  the 
following  way: 

A  validation  v,:  (£,  n,,  C,  nj)e\  is  said  to  intersect  the  sub-reduction  Rin)  below  a 
node  n  (denoted  by  “v,-  0  Rin)”)  if  there  exists  a  leaf  i»de  n  e  Rin)  such  that  n  falls 
between  n,  and  for  some  total  ordering  of  the  tasks  in  the  HTN.  In  other  words. 


V, :(£,«,,  C,  n^)0P(n)  iff  0(n,<n<nj) 


Using  the  definition  of  the  validation,  we  can  re-express  this  as 

[3/1' e  Rin)s.t.  childrenin')=0  fCl 

®  R(nU//  ^  ^  ^ 


(Note:  Given  that  n,<nj.  the  only  cases  in  which  ()in,<n'<nti)  are  (i)  n'  is  already  totally 
ordered  between  n,  and  nj,  i.e.,  □(rt,<n'</ij)  or  (//)  n'<nj /\  n* / or  (m) 
n,<n'  A  n'  ffn^  or  (iv)  n' /  n,  A  n'/  nj.  Using  the  transitivity  of  *'<”  relation,  we  can  sim¬ 
plify  this  disjunction  to  n, <n '<nj  ^  n^  ff  n*  \J  n^  /  n'.  ) 
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A  validation  v, ;  (£ ,  n, ,  C ,  nj)e  V  is  considered  a  p-condition  of  a  node  n  iff  v,  inter¬ 
sects  R(n)  and  neither  the  source  nor  the  destination  of  the  validation  belong  to  /?(«).  Thus, 
P-conditionsin)  =  {v,:  (E,  n,,  C,  /J<j)|vi€V;  £(«);  v,  0/?(/i)) 

From  this  definition,  it  follows  that  if  tlie  effects  of  any  node  of  R(n)  violate  the  validations 
corresponding  to  the  p-conditions  of  n ,  then  there  will  be  a  potential  for  harmful  interactions. 
As  an  example,  the  p-conditions  of  the  node  in  the  HTN  of  Figure  2  will  contain  the  valida¬ 
tion  (pn(B ,C .CXnc)  since  the  condition  On{B,C),  which  is  achieved  at  rti5 
would  have  to  persist  over  R(ny)  to  support  the  condition  (goal)  On(B,C)  at  The  p- 
conditions  are  useful  to  gauge  the  effect  of  changes  made  at  the  sub-reduction  below  a  node  on 
the  validations  external  to  that  sub-reduction.  They  are  of  particular  importance  in  localizing 
the  changes  to  the  plan  during  refitting  [15]. 

From  the  definition  of  p-conditions,  the  following  relations  follow: 

(1)  p-conditions(ni)  =  p-conditions(nc)  =  0. 

(2)  When  n  is  a  leaf  node,  (i.e.,  ciuldren{n)=^),  R{n)  will  be  (n ),  and  the  definition  of  p- 
conditions{n)  can  be  simplified  as  follows.  From  the  definition  of  0 , 

V,:  (£,  n,,  C,  n^)®  [n )  s  n, /n\J  /nsj  (n,<n<na)  s  -,(n<n,  V  n>nj) 

and,  thus  when  n  is  a  leaf  node 

P-conditionsin)  =  {v,:  ^£,  n,,  C,  n,j)|v,€V;  n,^;nj^n;  -i(«<n,  V  n>nj)] 

(3)  If  n^  e  children  in),  and  v^:  (E,  n^,  C,  n^i)  e  p-conditionsinc),  then  e  p- 
conditionsin)  iff  n,  ,nj  4  Rin).  This  follows  from  the  fact  that  if  ®Rinc)  then 

Bn'  e  Rin^)  which  satisfies  the  ordering  restriction  of  “0  Since  /?(nc)c  Rin),  we 
also  have  n'  e  Rin)  and  thus  Vg®Rin).  So,  as  long  as  n,,nj4Rin),  Vg  will  also  be  a 
p-condilion  of  n . 

(4)  If  n  is  not  a  leaf  node  and  v  e  p-conditionsin)  then  e  childrenin)  s.t.  v  e  p- 
conditionsing).  This  follows  from  the  fact  that  for  v  to  be  a  p-condition  of  n,  there 
should  exist  a  leaf  node  n'  belonging  to  Rin)  such  that  the  ordering  restriction  of  the 
*'0  ”  relation  is  satisfied.  But,  from  the  definition  of  sub-reduction,  any  leaf  node  of 
Rin)  should  also  have  to  be  a  leaf  node  of  the  sub-reduction  of  one  of  its  children.  So, 
Bng  B  childrenin)  s.t.  n'  e  Ring).  Moreover,  as  the  source  and  destination  nodes  of  v 
do  not  belong  to  £(/>),  they  will  also  not  belong  to  Ring). 

These  relations  provide  a  way  of  computing  the  p-conditions  of  a  non-leaf  node  from  the  p- 
conditions  of  its  children,  which  will  be  exploited  in  computing  the  armotations. 

§2.6.  Validation  States:  If  n  is  a  primitive  task  belonging  to  the  HTN,  then  we  define  struc¬ 
tures  called  preceding  validation  state.  A’’ in),  and  succeeding  validation  state.  A’ in),  as  fol¬ 
lows: 


A'^in)  =  e-preconditionsin)  kJ p-coruiitions{n) 

A‘{n)-  e-condiiions{n)  p-conditionsin) 

Thus,  the  validation  states  A'’(n)  and  A’(,n)  arc  collect  ons  of  validations  that  should  be 
preserved  by  the  state  of  the  world  preceding  and  following  the  execution  of  task  n ,  for  the 
rest  of  the  plan  to  have  a  consistent  validation  stnicture.  For  example,  the  plan  can  be  success¬ 
fully  executed  from  any  state  W  of  the  world  such  that 

V V :(£ ,n,,C,na)  e  A* (rii),  W  h-£ 

Thus  the  validation  states  can  be  used  to  gauge  how  a  change  in  the  expected  state  of  the 
world  will  affect  the  validation  structure  of  the  plan.  This  is  useful  both  in  reuse,  where  an 
existing  plan  is  used  in  a  new  problem  situation,  and  in  replanning,  where  the  current  plan 
needs  to  be  modified  in  response  to  execution  time  expectation  failures.  The  validation  states 
can  be  seen  as  a  generalization  of  strips’  triangle  tables  [6],  for  partially  ordered  plans. 

The  validation  states  also  provide  a  clean  framework  for  execution  monitoring  for  par¬ 
tially  ordered  plans.  If  EXEC  denotes  the  set  of  actions  of  the  plan  P  that  have  been  executed 
by  the  agent  until  now,  and  IF  denotes  the  current  world  state,  then  the  set  of  actions  of  the 
plan  that  may  be  executed  next,  E(P,W ^XEC),  is  computed  as  (see  [20]): 

£(£,VF,EXEC)  =  {n,  Iprimitiveirit)  AVv:(£,n,,C,nd)  €  A''(n,)  s.t.  d  EXEC,  W\-E  ) 

As  long  as  the  agent  executes  any  of  the  v  etions  in  £(£,W,EXEC)  next,  it  is  assured  of  follow¬ 
ing  the  plan,  while  taking  into  account  any  unexpected  changes  in  the  world  state.  When 
£(P,W,EXEC)=0,  replanning  (or  modification  of  the  current  plan  P)  will  be  necessitated  (see 
(20]). 

2.3.  Computing  Annotations 

In  the  PRIAR  framework,  at  the  end  of  a  planning  session,  the  HTN  showing  the  development  of 
the  plan  at  various  levels  of  abstraction  is  retained,  and  each  node  of  the  HTN  is  annotated  with 
the  following  infonnation:  (1)  Schema (n),  the  schema  instance  that  reduced  node  n  (2) 
Orderings (n),  the  ordering  relations  that  were  imposed  during  the  expansion  of  n  (see  §1.2)^ 
(3)  tf-pteconditions(rt)  (4)  e-conditions(n),  and  (5)  p-conditionsin). 

Schema (n)  and  Orderings (n)  are  remembered  in  a  straight  forward  way  during  the 
planning  itself.  The  rest  of  the  node  annotations  are  computed  in  two  phases:  First,  the  annota¬ 
tions  for  the  leaf  nodes  of  the  HTN  are  computed  with  the  help  of  the  set  of  validations^  V, 
and  the  partial  ordering  relations  of  the  HTN.  Next,  using  relations  between  the  annotations  of  a 

’  This  infonnation  is  useful  for  undoing  task  reductions  during  plan  modifications;  see  section  3.2.1. 

^  As  mentioned  previously,  the  set  of  validations  can  be  computed  directly  from  the  set  of  protection  intervals 
associated  with  the  plan.  Most  hierarchical  plannen  keep  an  explicit  record  of  the  protection  intervals  underlying 
the  plan.  NONUN  (30j,  for  example,  maintains  this  information  in  its  OOST  dau  structure. 


node  and  its  children,  the  annotations  are  propagated  to  non-leaf  nodes  in  a  bottom  up 
breadth-first  fashion.  The  exact  algorithms  are  given  in  [13],  and  are  fairly  straightforward  to 
understand  given  the  development  of  the  previous  sections.  If  Np  is  the  length  of  the  plan  (as 
measured  by  the  number  of  leaf  nodes  of  the  htn),  the  time  complexity  of  annotation  computa¬ 
tion  can  be  shown  to  be  0(Np)  [13].  Note  that  the  ease  of  annotation  computation  is  to  a 
large  extent  an  advantage  of  integrating  planning  and  plan  modification,  as  all  the  relevant 
information  is  available  in  the  plan-time  datastructures.  With  respect  to  storage,  the  important 
point  to  be  noted  is  that  PRIAR  essentially  remembers  only  the  HTN  representing  the  develop¬ 
ment  of  the  plan  and  not  the  whole  explored  search  space.  If  the  individual  validations  are 
stored  in  one  place,  and  the  node  annotations  arc  implemented  as  pointers  to  these,  the  iiKrease 
in  storage  requirements  (as  compared  to  the  storage  of  the  un-annotated  HTN)  is  insignificant 
This  small  increase  in  the  storage  requirements  can  be  justified  in  light  of  the  multiple  uses  of 
the  stored  informatioa 

While  the  procedures  discussed  above  compute  the  annotations  of  a  HTN  in  one-shot, 
often  during  plan  modification,  PRIAR  needs  to  add  and  remove  validations  from  the  HTN  one  at 
a  time.  To  handle  this,  PRIAR  also  provides  algorithms  (called  Add-Validation  and 
Remove -Validation  )  to  update  node  annotations  consistently  when  incrementally  adding  or 
deleting  validations  from  the  HTN  [13].  PRIAR  uses  these  procedures  to  re-annotate  the  HTN  and 
to  maintain  a  consistent  validation  structure  after  smaft  changes  are  made  to  the  htn  during  the 
modification  process.  They  can  also  be  called  by  the  planner  any  time  it  establishes  or 
removes  a  new  validation  (or  protection  interval)  during  the  development  of  the  plan,  to 
dynamically  maintain  a  consistent  validation  structure.  The  time  complexity  of  these  algorithms 
is  0(Np).  Whenever  these  procedures  add  or  remove  a  validation,  they  also  update  the  protec¬ 
tion  intervals  (IT)  of  the  HTN  appropriately. 

3.  Modification  by  Annotation  Verification 

We  will  now  turn  to  the  plan  modification  process,  and  demonstrate  the  utility  of  the  annotated 
validation  structure  in  guiding  plan  modification.  Throughout  the  ensuing  discussion,  we  will 
be  following  the  blocks  world  example  case  of  modifying  the  plan  for  the  three  block  stacking 
problem  3BS  (i.e.,  /?®=  3BS)  shown  on  the  left  side  in  Rgure  3  to  produce  a  plan  for  a  five 
block  stacking  problem  S5BS1^  (i.e. ,  S5BS1),  shown  on  the  right  side.  We  shall  refer  to 

this  as  the  3BS->SSBS1  example. 

3.1.  Mapping  and  Interpretation 

In  PRIAR,  the  set  of  possible  mappings  between  [P°JR°]  and  P"  are  found  through  a  partial 
unification  of  the  goals  of  the  two  problems.  There  are  typically  several  semantically  consistent 
mappings  between  the  two  planning  situations.  While  the  PRIAR  modification  framework 


*  It  may  be  interesting  to  note  that  S5BS1  contains  an  instance  of  what  is  known  as  the  Sussman  Anomaly  [3] 
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Figure  3.  3BS-»S5BS1  Modifkation  problem 


would  be  able  to  succeed  with  any  of  those  mappings,  selecting  the  right  mapping  could  con¬ 
siderably  reduce  the  cost  of  modification.  The  mapping  and  retrieval  methodology  used  by 
PRIAR  [13,17]  achieves  this  by  selecting  mappings  based  on  the  number  and  type  of  incon¬ 
sistencies  that  would  be  caused  in  the  validation  structure  of  /?**.  While  the  details  of  this  stra¬ 
tegy  are  beyond  the  scope  of  this  paper,  a  brief  discussion  appears  in  section  3.4.2.  For  the 
present,  we  shall  simply  assume  that  such  a  mapping  is  provided  to  us.  Gt  should  be  noted 
that  the  mapping  stage  is  not  important  when  PRIAR  is  used  to  modify  a  plan  in  response  to 
incremental  changes  in  its  specification,  as  is  the  case  during  incremental  plaiming  or  replan¬ 
ning  for  example  [20]) 

The  purpose  of  the  inteipretation  procedure  is  to  map  the  given  plan,  R**  along  with  its 
annotations  into  the  new  planning  situation  F" ,  marking  the  differences  between  the  old  and 
new  planning  situations.  These  differences  serve  to  focus  the  annotation  verification  procedure 
(see  section  3.2.1.)  on  the  inconsistencies  in  the  validation  structure  of  the  interpreted  plan. 
Let  /"  and  G°  be  the  partial  descriptions  corresponding  to  the  required  initial  state,  and  the  set 
of  goals  to  be  achieved  by  F®  respectively.  Similarly,  let  /"  and  G"  be  the  corresponding 
descriptions  for  the  new  problem  P".  The  interpreted  plan  R‘  is  constructed  by  mapping  the 
given  plan  P®  along  with  its  annotations  into  the  new  problem  situation,  with  the  help  of  the 
mapping  a.  Next,  the  inteipreted  initial  state  /*,  and  the  interpreted  goal  state,  G'  are  com¬ 
puted  as  /*  =  a  and  G*  =  G"UG®  a  (where  refers  to  the  operation  of  object  sub¬ 

stitution).  Fmally,  some  facts  of  /*  and  G*  are  marked  to  point  out  the  following  four  types  of 
differences  between  the  old  and  new  planning  situations: 

(1)  A  description  (fact)/  6  /'  is  marked  an  out  fact  iff  (/  e  /®a)  A  (/"  N-  /). 

(2)  A  description  (fact)  /  e  /'  is  marked  a  new  fact  iff  (/"  e  /")  A  (/"a  \i-f). 

(3)  A  description  (goal)  g  e  G'  is  marked  an  extra  goal  iff  (gd  G®  a)  A  (g  e  G"). 

(4)  A  description  (goal)  (g  e  G‘)  is  marked  an  unnecessary  goal  iff 

(g  e  G®  a)  A  (gd  G").  At  the  end  of  this  processing,  R‘,  /'  and  G*  are  sent  to  the 
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annoiaiion  verification  procedure. 

3.1.1.  Example 

Let  us  assume  that  the  mapping  strategy  selects  a  =  [A-^K  JS-^J  .C-^I]  as  the  mapping  from 
3BS  to  S5BS1.  Figure  4  shows  the  result  of  interpreting  the  3BS  plan  for  the  S5BS1  problem. 
With  this  mapping,  the  facts  Clear (L)  and  On(K  .Table),  which  are  true  in  the  interpreted  3BS 
problem,  arc  not  true  in  the  input  specification  of  S5BS1.  So  they  are  marked  out  in  /*.  The 
facts  Clear  (L),  On  (M  .Table),  On  {I, Table),  On(LM)  and  On(KJ)  are  tnic  in  S5BS1  but 
not  in  the  interpreted  3BS.  These  arc  marked  as  new  facts  in  /*.  Similaily,  the  goals 
On(LJC)  and  Clear  (bf)  of  S5BS1  are  not  goals  of  the  interpreted  3BS  plan.  So,  they  are 
marked  extra  goals  in  G'.  There  are  no  unnecessary  goals. 

3.2.  Annotation  Verification  and  Refit  Task  Specification 

At  the  end  of  the  interpretation  procedure,  /?'  may  not  have  a  consistent  validation  structure 
(see  §2.2)  as  the  differences  between  the  old  and  the  new  problem  situations  (as  marked  in  /' 
and  G')  may  be  causing  inconsistencies  in  the  validation  structure  of  R‘.  These  inconsisten¬ 
cies  will  be  referred  to  as  applicability  failures,  as  these  are  the  reasons  why  R'  cannot  be 
directly  applied  to  F".  The  purpose  of  the  annotation  verification  procedure  is  to  modify  R' 
such  that  the  result,  R‘‘ ,  will  be  a  partially  reduced  HTN  with  a  consistent  validation  structure. 

The  annotation  verification  procedure  achieves  this  goal  by  first  localizing  and  character¬ 
izing  the  applicability  failures  caused  by  the  differences  in  /*  and  G',  and  then  appropriately 
modifying  the  validation  structure  of  to  repair  those  failures.  It  groups  the  applicability 
failures  into  one  of  several  classes  depending  on  the  type  of  the  inconsistencies  and  the  type  of 
the  conditions  involved  in  those  inconsistencies.  Based  on  this  classification,  it  then  suggests 
appropriate  repairs.  The  repairs  involve  removal  of  unnecessary  parts  of  the  HTN  and/or  addi¬ 
tion  of  non-primitive  tasks  (called  “refit  tasks”)  to  establish  missing  and  failing  validations.  In 
addition  to  repairing  the  inconsistencies  in  the  plan  validation  structure,  the  annotation 
verification  process  also  uses  the  notion  of  p  -phantom-validations  (see  below)  to  exploit  any 
serendipitous  effects  to  shorten  the  plan.  Figure  5  provides  the  top  level  control  structure  of 
the  annotation  verification  process. 

The  individual  repair  actions  taken  to  repair  the  different  types  of  inconsistencies  are 
described  below;  they  make  judicious  use  of  the  node  annotations  to  modify  R‘  appropriately. 
The  specifications  of  the  exact  procedures  used  by  all  these  modification  actions  can  be  found 
in  [13]. 


3.2.1.  Unnecessary  Validations — Pruning  Unrequired  Parts 

If  the  supported  condition  of  a  validation  is  no  longer  required,  then  that  validation  can  be 
removed  from  the  plan  along  with  all  the  parts  of  the  plan  whose  sole  purpose  is  supplying 
those  validations.  The  removal  can  be  accomplished  in  a  clean  fashion  with  the  help  of  the 
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Fi|;ure  4.  Interpreted  Plan  for  3BS->S5BSt 
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Procedure  Annotation -Verificcuion  ( ) 

input:  /?*:  Interpreted  plan,  7‘:  Interpreted  input  state,  C*:  Interpreted  goal  state 
begin 

foreach  g  e  G*  SJ,  g  is  nuvkcd  as  an  unnecessary^goal 
do  find  g  sj.  C=g 

Prune-Validationiy )  od 

foreach  g  e  G*  SJ.  g  is  marked  as  an  extra-goal 
do  Repair-Missing-Validaiionig  iccndinon ,  rtc inode)  od 
foreach  /  e  /*  s.t.  f  is  marked  as  an  out-fact 
do  foreach  v:(E €  A'(n/)  s.f.  £=/ 

do  if  £'  €  /*  j.r.  £'  is  marked  new  A  £'I“C  t*Verificaiony 


then  do  Remov€-VaIidation(v) 

Add-Va!idation(^  ':{£  >/  .C  ^f))  od 
elseif  (ype(C)^Precondition 

then  Repair-Fai!ing-Precondition-Validation{v ) 
elseif  type  (C  ^Phantom  is  a  phantom  node*/ 
then  Repair-Failing-Phantom-Validation{v ) 
elseif  type  (Cy^Filter-Condiiion 

then  Repair-Failing-Filter-Condition-Validationiv)  od  od 
foreach  v:(E ,nj)  e  V  sJ. 

A  £  e  /*A  E  is  marked  new  in  /'  ^ checking  for  serendipitous  effects^ ! 
do  Exploit-P~Pkantom-Validation{v)  od 

end 


Figure  S.  Annotation-Verification  Procedure 

annotations  on  /?*:  After  removing  an  unnecessary  validation  from  the  HTN  (which  will  also 
involve  incrementally  re-annotating  the  HTN,  see  section  2,3).  the  HTN  is  searched  for  any  node 
riy,  that  has  no  e -conditions.  If  such  a  node  is  found,  then  its  sub-reduction,  has  no 

useful  purpose,  and  thus  can  be  removed  from  the  HTN.  This  removal  turns  the  e -preconditions 
of  riy  into  unnecessary  validations,  and  they  are  handled  in  the  same  way  recursively. 

The  procedure  Prune-Validation  in  Figure  6  gives  the  details  of  this  process.  After 
removing  the  unnecessaiy  validation  v  from  the  plan,  it  checLs  to  see  if  there  arc  any  sub- 
reductions  that  have  no  useful  effects  Qines  3-5).  (Because  of  the  explicit  representation  of  the 
validation  structure  as  annotations  on  the  plan,  this  check  is  straightforward.)  If  there  arc  such 
sub-reductions,  they  have  to  be  removed  from  the  HTN  (lines  6-16),  This  involves  removing 
all  the  internal  validations  of  that  sub-reduction  from  the  HTN  Qines  7-8),  and  recursively  prun¬ 
ing  the  validations  corresponding  to  the  external  preconditions  of  that  sub-reduction  Gines  9- 
10).  This  latter  action  is  to  ensure  that  there  won’t  be  any  parts  of  the  HTN  whose  sole  pur¬ 
pose  is  to  supply  validations  to  the  parts  that  are  being  removed.  The  Removed-Validation 
procedure  Gine  8)  not  only  removes  the  given  validation,  but  also  updates  the  validation  struc¬ 
ture  (V)  and  the  protection  intervals  (TI)  of  the  HTN  consistently.  Finally,  the  sub-reduction  is 
unlinked  from  the  HTN  Gines  12-14),  and  the  partial  ordering  on  the  HTN  (p)  is  updated  so 
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Procedure  Prune- Validation  (v  :(E  ,n,  ,C  ^j)mts:(P  :(T ,0  Xf)J  J))) 

1  begin 

2  Ra?xGve-Validat:on{v) 

3  if  e  -conditions(n,  )^0 

4  then  do  find  n  e  {n, )  anccstors{n,)  s.t, 

5  €  -condiiions(n )  =  0  A  e  -conditions(/>arert/  {n  »  ^  0 

6  I* Remove  the  sub-reduction  below  n  '*/ 

7  foreach  n '  g  R{n)  s.t.  children (n 0^0 

8  do  foreach  v'  €  e -condilions(nO 

9  do  R€riove-vaiidation(v ')  od 

10  foreach  v"  e  e-prccondiiions(n) 

11  do  Prune -Validaiion  (v  'O  od 

12  /*  unlinking  R{n)  from  HTN  V 

13  r 

14  Ti-T-R{n) 

15  D  6  D  A  d  c/?(n)) 

16  Update-Ord€rings{0,R{n))  od  fi 

17  end 


Figure  6.  Procedure  for  repairing  unnecessary  valida(»ons 


that  the  ordering  relations  that  were  imposed  because  of  the  expansions  involved  in  Rin)  are 
retracted.  Tiiis  backtracking  is  accomplished  with  the  help  of  the  orderings  field  of  each  node 
in  i?(n)  (see  section  2.3)  which  stores  the  ordering  relations  that  were  imposed  because  of  the 
expansion  below  that  node.  The  procedure  involves:  (i)  Retracting  from  O  all  the  ordering 
relations  that  are  stored  in  the  orderings  fiCiJ  of  the  removed  nodes  (/?(n)),  and  («)  Appropri¬ 
ately  redirecting^  any  remaining  ordering  relations  of  O  involving  the  removed  nodes  (these 
correspond  to  the  orderings  that  were  inherited  from  the  ancestors  of  n;  see  §1.2). 

The  structure  of  the  HTN  at  the  end  of  this  procedure  depends  to  a  large  extent  on  the 
importance  of  the  validation  that  is  being  removed  (that  is,  how  much  of  the  HTN  is  directly  or 
indirectly  present  solely  for  achieving  this  validation).  The  Prune-Validation  procedure 
removes  exactly  those  parts  of  the  plan  that  become  completely  redundant  because  of  the 
unnecessary  validation.  It  will  not  remove  any  sub-reduction  that  has  at  least  one  e-condition 
(corresponding  to  some  useful  effect).  Many  previous  plan  modification  strategies  (such  as 
[6,9])  did  not  have  this  flexibility.  Explicit  representation  of  the  validation  structure  makes 
this  possible  in  PRiAR’s  framework.  There  is,  however,  a  trade-off  involved  here:  the  strategy 
adopted  by  the  Prune-Validation  procedure  is  appropriate  as  long  as  the  goal  is  to  reduce  the 
cost  of  plaiuiing  (refitting).  However  it  should  be  noted  that  if  the  cost  of  execution  of  the 
plan  were  paramount,  then  it  would  be  necessary  to  see  if  the  remaining  useful  effects  of  the 
sub-reduction  could  be  achieved  in  an  alternate  way  that  would  incur  a  lower  cost  of  executioa 
To  lake  an  extreme  example,  suppose  the  plan  achieves  two  of  its  goals,  taking  a  flight  and 
reading  a  paper,  by  buying  a  paper  at  the  airport  If  R^  \s  being  reused  in  a  situation  where 

•  To  a  sibling  of  n  in  case  of  pruned  reducrion.  and  to  n  in  the  case  of  a  replaced  reduction  (see  3.23). 
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itio  agent  (levs  not  have  to  lake  a  (light,  it  will  be  better  to  satisfy  the  goal  of  buying  the  paper 
in  an  alternate  way.  rather  than  by  going  to  the  airport.  This  type  ol  analysis  can  be  done  with 
the  help  of  the  'levels'  of  validations  (see  section  2.1);  We  might  decide  to  remove  a  sub- 
reduction  l\(n)  and  achieve  its  useful  effects  in  an  alternate  way  if  the  levels  of  e-conditions  of 
n  which  arc  removed  are  ‘significantly’  higher  Ilian  the  levels  of  the  remaining  e-conditions  of 
n .  PRIAR  currently  docs  not  do  tltis  type  of  analysis  while  pruning  a  validation. 

3.2.2.  Missing  Validations— Adding  Tasks  for  Achieving  Extra  Goals 

If  a  condition  C  of  a  node  nj  is  not  supported  by  any  validation  belonging  to  the  set  of  vali¬ 
dations  of  the  plan,  V,  then  there  is  a  missing  validation  corresponding  to  that  condition-node 
pair.  Since,  art  extra  goal  is  any  goal  of  the  new  problem  that  is  not  a  goal  of  the  old  plan,  it 
is  un-supponed  by  any  validation  in  R‘.  The  general  procedure  for  repairing  missing  valida¬ 
tions  (including  the  extra  goals,  which  are  considered  conditions  of  «-)  is  to  create  a  refit  task 
of  the  form  n„.Achicve[G],  and  to  add  it  to  the  HTN  in  such  a  way  that  /»/<«„ <n^,  and 
parent (n„)=parenf(_nj).  The  new  validation  v„:(p ,n„,G ,nj)  will  now  support  the  condition 
G .  Before  establishing  a  new  validation  in  this  way  PRIAR  uses  the  planner’s  truth  criterion 
(interaction  detection  mechanisms)  to  make  sure  whether  that  validation  introduces  any  new 
failing  validations  into  the  plan  (by  causing  harmful  interactions  with  the  already  established 
protection  intervals  of  the  plan).  The  incremental  annotation  procedures  are  then  used  to  add 
the  new  validation  to  the  HTN.  Notice  that  no  a  priori  commitment  is  made  regarding  the 
order  or  the  way  in  which  the  condition  G  would  be  achieved;  such  commitments  are  made  by 
the  planner  itself  during  the  refitting  stage. 

3.2J.  Failing  Validations 

The  facts  of  /'  which  are  marked  "out"  during  the  interpretation  process,  may  be  supplying 
validations  to  the  applicability  conditions  or  goals  of  the  interpreted  plan  /?'.  For  each  failing 
validation,  the  annotation  verification  procedure  first  attempts  to  see  if  that  validation  can  be 
re-established  locally  by  a  new  effect  of  the  same  node.  If  this  is  possible,  the  validation 
structure  will  be  changed  to  reflect  this.  A  simple  example  would  be  the  following:  Suppose 
there  is  a  condition  Greater (B  ,1)  on  some  node,  and  the  fact  Equal{B  ,\0)  in  the  initial  state 
was  used  to  support  that  condition.  Suppose  further  that  in  the  new  situation  EquaKfiAO)  is 
marked  out  and  Equal  (B  ,8)  is  marked  new .  In  such  a  case,  it  should  be  possible  to  establish 
the  condition  just  by  redirecting  the  validation  to  Equal  (B  ,8). 

When  the  validations  cannot  be  established  by  such  local  adjustments,  the  structure  of  the 
imt  has  to  be  changed  to  account  for  the  failing  validations.  ’Tlic  treatment  of  such  failing 
validations  depends  upon  the  types  of  the  conditions  that  are  being  supported  by  the  validation. 
We  distinguish  three  types  of  validation  failures — ^validations  supporting  preconditions,  phan- 
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tom  goals^  and  filter  conditions  respectively — and  discuss  each  of  them  in  turn  below. 

3.2.3.I.  Failing  Precondition  Validations 

If  a  validation  v  :(E  ,n^  ,C  ,n^)  supporting  a  precondition  of  some  node  in  the  HTN  is  found  to  be 
failing,  because  its  supporting  effect  E  is  marked  out,  it  can  simply  be  reachieved.  The  pro¬ 
cedure  involves  creating  a  "'fit  task,  n„iAchieve[E ),  to  re-establish  the  validation  v,  and 
adding  it  to  HTN  in  such  i  way  that  nj<n„<nd  and  parent {n„)  parenting).  The  valida¬ 
tion  structure  of  the  plan  is  updated  so  that  the  failing  validation  v  is  removed  and  an 
equivalent  validation  v''.(E ,nf,C is  added.  (This  addition  does  not  introduce  any  further 
inconsistencies  into  the  validation  structure  (see  section  4.2.1).)  Finally,  the  annotations  on  the 
other  nodes  of  the  HTN  are  adjusted  incrementally  to  reflect  this  change. 

32.3,2.  Failing  Phantom  Validations 

If  a  validation  :(£  ,n^  ,C  is  found  to  be  faUing  and  is  a  phantom  goal,  then  Vp  is  con¬ 
sidered  a  failing  phantom  validatioa  If  the  validation  supporting  a  phantom  goal  node  is  fail¬ 
ing,  then  the  node  cannot  remain  phantom.  The  repair  involves  undoing  the  phantomization,  so 
that  the  planner  would  know  that  it  lias  to  re-achieve  that  goal.  This  step  essentially  involves 
backtracking  over  the  phantomization  decision  and  updating  the  HTN  appropriately  (similar  to 
the  process  done  in  the  Prune— Validation  procedure  (Figure  6,  lines  12-16).  Once  this  change 
is  made,  the  failing  validation  Vp  is  no  longer  required  by  the  node  n^.  and  so  it  is  removed 
(updating  V  and  fl). 

32.33.  Failing  Filter  Condition  Validations 

In  contrast  to  the  validations  supporting  the  preconditions  and  the  phantom  goals,  the  valida¬ 
tions  supporting  failing  filter  conditions  caimot  be  reachieved  by  the  planner.  Instead,  the  plan¬ 
ning  decisiotis  which  introduced  those  filter  conditions  into  the  plan  have  to  be  undone.  That 
is,  if  a  validation  Vf  .{E,n,,Cf,n^)  supporting  a  filter  condition  Cf  of  a  node  n^  is  failing,  and 
rt'  is  the  ancestor  of  n^  whose  reduction  introduced  Cf  into  the  HTN  originally,  then  the  sub¬ 
reduction  has  to  be  replaced,  and  n’  has  to  be  re-reduced  with  the  help  of  an  alternate 
schema  instance.  So  as  to  least  affect  the  validation  structure  of  the  rest  of  the  HTN,  any  new 
reduction  of  n'  would  be  expected  to  supply  (or  consume)  the  validations  previously  supplied 
(or  consumed)  by  the  .  placed  reduction.  Any  validations  not  supplied  by  the  new  reduction 
would  have  to  be  re-established  by  alternate  means,  and  the  validations  not  consumed  by  the 
new  reduction  would  have  to  be  pruned.  Since  there  is  no  way  of  knowing  what  the  new 


’  The  difference  between  a  precondition  validation  and  a  phantom  goal  validation  is  largely  a  matter  of  how 
the  corresponding  conditions  arc  specified  in  the  task  reduction  schemas.  In  nonun  terminology  [29),  the  precondi¬ 
tion  validations  support  the  “unsupervised  conditions"  of  a  schema,  while  the  phantom  goal  validations  support 
the  "supervised  conditions"  of  a  schema. 
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reduction  will  be  until  the  refitting  time,  this  processing  is  deferred  until  then.® 

The  procedure  shown  in  Figure  7,  details  the  treatment  of  this  type  of  validation  failure 
during  annotation  verification.  In  line  3.  it  finds  the  node  n'  that  should  be  re-reduced  by 
checking  the  filter  conditions  of  the  ancestors  of  Lines  5-18  detail  changes  to  the  validation 
structure  of  the  HTN.  Any  e-conditions  of  the  nodes  belonging  to  R(n')  are  redirected  to  n  \  if 
they  support  nodes  outside  R(n')  (lines  6-9).  Otherwise,  such  e-conditions  represent  internal 
validations  of  R(n'X  and  are  removed  from  the  validation  structure  Qine  10).  At  the  end  of 
this  processing,  all  the  useful  external  effects  of  R(n^  have  n '  as  their  source.  Similar  pro¬ 
cessing  is  done  for  the  e -preconditions  of  the  nodes  of  R(n^  (lines  12-18).  Finally,  all  the 
descendants  of  n '  are  removed  from  the  HTN  (lines  20-22),  and  the  partial  orderings  of  HTN  are 
updated  to  reflect  this  removal  (line  23).  Apart  from  removing  the  orderings  imposed  by  the 
expansions  of  nodes  in  descendants this  step  also  involves  redirecting  any  ordering  rela¬ 
tions  that  were  inherited  from  ancestors  of  n*  back  to  n'  (see  the  discussion  in  section  3.2.1). 

Procedure  Repair-Failing-Filter-Condition-Validation  {Vf:(E/isyC,nti),  Krs:(P  :(J' ,0  Jl)J*  J))) 

1  begin 

2  Remov€‘VaUdation(Vf) 

3  findn'e  Ancestors s,t,  C  e  fiiter-condidons(n') 

4  I* replace  reduction  below  n  '*/ 

5  foreach /ic  6  R{n')sJ.  children (nc)-0 

6  do  foreach  j)  e  e-conditions(n^) 

7  do  if  v'  €  e -conditions(/i  0 

8  then  do  Remov€-Validation{v ') 

9  Add-Validation(v  ":(E  >  \C  >  '4)  od 

1 0  else  Remove*Validation{y 

11  hod 

12  foreach  e  e-preconditions(n^) 

13  do 

14  if  v'e  e -preconditions(/i 0 

1 5  then  do  Remove-Validation(v  0 

16  Add-Vaiidation(v  ";(£  > ')  od 

17  else  Remove-Validation{v^  fi 

18  od  od 

19  /*  unlinking  descendants  in')  from  HTN  */ 

20  r*  T*-d€scendents(n') 

21  T  4r-T  -descendants  (n ') 

22  D  4-  D-[d\d  e  D  f\  dQ  descendants  in')  ] 

23  Vpdate’OrderingsiO  y  descendants  in))  od  fi 

24  /♦Mark  n'  as  a  refit-iask  of  type  replace-reduction*/ 

25  r  4-  7  U  [n'] 

26  refit  task-typein')  4-  "*replace-reduction'* 

27  end 


Figure  7.  Procedure  for  repairing  failing  filter  condition  validations 


•  This  type  of  applicability  failure  is  very  serious  as  it  may  require  replacement  of  potentially  large  parts  of 
the  plan  being  reused,  there  by  increasing  the  cost  of  refitting.  In  [13, 17],  we  show  that  PRlAR’s  retrieval  and  map¬ 
ping  strategy  tends  to  prefer  reuse  candidates  that  have  fewer  applicability  failures  of  this  type. 
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Finally,  n'  now  constitutes  an  unreduced  refit-task  and  so  it  is  added  to  T  Qines  25-26). 
(Notice  that  a  difference  between  this  and  the  Prune -Validation  procedure  is  that  in  this  case 
the  e  -preconditions  of  the  replaced  sub-reduction  are  redirected  rather  than  praned.) 

3.2.4.  F-Phantom-Validations — ^Exploiting  Serendipitous  Effects 

When  R°  is  being  reused  in  the  new  planning  situation  of  P",  it  is  possible  that  after  the 
interpretation,  some  of  the  validations  that  R‘  establishes  via  step  addition  can  now  be  esta¬ 
blished  directly  from  the  new  initial  state.  Such  validations  are  referred  to  as  p -phantom  vali¬ 
dations.  More  formally,  a  validation  Vp  ;(£  ,nj  ,C  .n^)  is  considered  a  p -phantom-validation  of 
R‘  if  n^^ni  and  /"  \~E.  Exploiting  such  serendipitous  effects  and  removing  the  parts  of  the 

plan  rendered  redundant  by  such  effects  can  potentially  reduce  the  length  of  the  plan.  Once 
the  annotation  verification  procedure  locates  such  validations,  PRIAR  checks  to  see  if  they  can 
actually  be  established  from  the  new  initial  state.  This  analysis  involves  reasoning  over  the 
partially  ordered  tasks  of  the  HTN  to  see  if  through  possible  introduction  of  new  ordering  rela¬ 
tions,  an  effect  of  nj  can  be  made  to  satisfy  the  applicability  condition  supponed  by  this  vali¬ 
dation.  The  facilities  of  typical  nonlinear  planners  can  be  used  to  carry  out  this  check.  When 
a  p-phantom  validation  Vp  is  found  to  be  establishable  from  n/ ,  the  parts  of  the  plan  that  are 
currently  establishing  this  validation  can  be  pruned.  This  is  achieved  by  pruning  Vp  (see  sec¬ 
tion  3.2.1).  Qirrently,  we  do  not  allow  priar  to  add  steps  (c/.  white  knights  [3])  or  cause 
new  interactions  while  establishing  a  p-phantom  validation,  and  exploit  the  serendipitous 
effects  only  if  doing  so  will  not  cause  substantial  revisions  to  the  plan. 

3.2.5.  Example 

Figure  8  shows  R“,  the  HTN  produced  by  the  annotation  verification  procedure  for  the 
3BS-)S5BS1  example.  The  input  to  the  annotation  verification  procedure  is  the  interpreted 
plan  R'  discussed  in  section  3.1.  In  this  example,  R'  contains  two  missing  validations 
corresponding  to  extra  goals,  a  failing  phantom  validation  and  a  failing  filter  condition  valida- 
tioa  The  fact  On(K, Table),  which  is  marked  out  in  /*,  causes  the  validation 
ipn{K ,Table),ni,On{K .Table) in  R‘  to  fail.  Since  this  is  a  failing  filter  condition  valida¬ 
tion®,  the  reduction  that  first  introduced  this  condition  into  the  HTN  would  have  to  be  replaced. 
In  this  case,  the  condition  On(K , Table)  came  into  the  HTN  during  the  reduction  of  node 
n^iDolPutoniK  J)].  Thus,  the  annotation  verification  process  removes  Rin^)  from  the  HTN, 
and  adds  a  replace  reduction  refit  task  n^\Do[Puton{K J)].  The  e -preconditions  of  the 
replaced  reduction,  {Clear(K),n^,Clear(K),n^^  and  (flear(J),ni,Clear(J),ni^  ,  arc  redirected 
such  that  the  refit  task  ng  becomes  their  destination.  SimUarly  the  e  -condition  of  the  replaced 

*  We  follow  the  convention  of  [30]  and  classify  OniK.’x)  as  a  filter  condition  rather  than  a  precondition. 
Some  effects  of  the  plan  depend  on  the  binding  of  ?x  and  one  way  of  correctly  propagating  the  effects  when  the 
binding  of  ?x  changes  is  to  treat  this  reduction-time  assumption  as  a  filter  conditioa 
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Figure  8.  A nnotatlon-ve rifled  Pian  for  3BS->S5BS1 


reduction,  tpn(,K  J).nx(,,Or «g)  is  redirected  such  that  becomes  the  source.  These 
la-st  two  steps  ensure  tha'  ible  reduction  of  /J9  will  be  aware  of  the  fact  that  it  is 

expected  to  supply  the  e  -<  and  consume  r  -preconditions  of  the  replaced  reduction. 

Next,  the  fact  .. which  is  marked  out  in  /'  causes  the  validation 

(Clear Clear to  fail.  Since  this  validation  supports  the  phantom  goal  node  tlie 
annotation  verification  procedure  undoes  the  phantomization  and  converts  into  a  refit  task 
ns:AchievelClear(l)]  to  be  reduced.  Once  this  conversion  is  made,  longer  needs  the  failing 
validation  from  «/.  and  it  is  removed. 

Finally,  the  goals  Clear (M)  mi  On(L  Ji)  of  G'  arc  extra  goals,  and  arc  not  supported 
by  any  validation  of  the  HTN.  So,  the  refit  tasks  nxQAchieve[On{LJ()]  and 
nxyAchieve{Clear{M)]  arc  created  and  added  to  the  HTN,  in  parallel  to  the  existing  plan  such 
that  ni<niQ<nQ  and  n/<n  TTie  node  «io  now  supports  the  validation 

(On(LJi),nio,OniLJC),nG)  and  the  node  nji  supplies  the  validation 
(Clear{M),nii,Clear(M),no). 

Notice  that  the  HTN  shown  in  this  figure  corresponds  to  a  partially  reduced  task  netwo± 
which  consists  of  the  applicable  parts  of  the  old  plan  and  the  four  refit  tasks  suggested  by  the 
annotation  verification  procedure.  It  has  a  consistent  validation  structure,  but  it  contains  the 
unreduced  refit  tasks  njo,  nn.  '>9  and  R5. 

3.2.6.  Complexity  of  Annotation  Verification 

In  [13],  we  show  that  the  repair  actions  involved  in  the  annotation  verification  process  can  all 
be  carried  out  in  O (Np),  except  for  the  steps  involving  interaction  detection  when  new  valida¬ 
tions  are  introduced  during  the  repair  of  missing  validations  and  p  -phantom  validations.  This 
latter  step  essentially  involves  checking  for  the  truth  of  an  assertion  in  a  partially  ordered  plan. 
It  is  known  that  under  the  TWEAK  representation  (which  does  not  allow  conditional  effects  and 
state  independent  domain  axioms),  this  step  can  be  carried  out  in  O (Np)  time  [3].  Thus,  the 
worst  case  complexity  of  the  repair  actions  is  0(Np).  Since  there  cannot  be  more  than  I VI 
failing  validations  in  a  plan,  the  complexity  of  the  overall  aimotation  verification  process  itself 
is  0(\\\Np)  (where  IVI  <  ^p  as  mentioned  previously).  Thus,  the  annotation  verification 
process  is  of  polynomial  (O  (Np) )  complexity  in  the  length  of  the  plan. 

3.3.  Refitting 

At  the  end  of  the  annotation  verification,  R“  represents  an  incompletely  reduced  HTN  with  a 
consistent  validation  structure.  To  produce  an  executable  plan  for  /*",  R“  has  to  be  com¬ 
pletely  reduced.  This  process,  called  refitting,  essentially  involves  reduction  of  the  refit  tasks 
that  were  introduced  into  R“  during  the  annotation  verification  process.  The  responsibility  of 
reducing  the  refit  tasks  is  delegated  to  the  planner  by  sending  R“  to  the  planner.  An  important 
difference  between  refitting  and  from-scratch  (or  generative)  planning  is  that  in  refitting,  the 
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planner  starts  with  an  already  partially  reduced  HTN.  For  this  reason,  solving  P"  by  reducing 
P"  is  less  expensi/e  on  tlie  average  than  solving  P"  from  scratch. 

The  procedurj  used  for  reducing  refit  tasks  is  fairly  similar  to  the  one  the  planner  nor¬ 
mally  uses  for  reducing  non-primitive  tasks  (see  section  1.4),  with  one  important  extension. 
An  important  consideration  in  refitting  is  to  minimize  the  disturbance  to  the  applicable  parts  of 
R°  during  the  reduction  of  the  refit  tasks.  Ideally,  it  should  leave  any  already  established  pro¬ 
tection  intervals  of  HTN  unaffected.  To  ensure  this  conservatism  of  refitting,  the  default 
schema  selection  procedure  is  modified  in  such  a  way  that  for  each  refit  task,  n^,  it  selects  a 
schema  instance  that  is  expected  to  give  rise  to  the  least  amount  of  disturbance  to  the  valida¬ 
tion  structure  of  P".  The  annotations  on  n,  guide  this  selection  by  estimating  the  effect  of 
the  reduction  of  on  the  rest  of  the  plan.  (Section  3.4.1  contains  a  brief  discussion  of  this 
heuristic  control  strategy.)  Once  the  planner  selects  an  appropriate  schema  instance  by  this  stra¬ 
tegy,  it  reduces  the  refit  task  by  that  schema  instance  in  the  noimal  way,  detecting  and  resolv¬ 
ing  any  interactions  arising  in  the  process. 

A  special  consideration  arises  during  the  reduction  of  refit  tasks  of  type  replace- 
reduction.  After  selecting  a  schema  instance  to  reduce  such  refit  tasks,  priar  might  have  to  do 
some  processing  on  the  HTN  before  starting  the  task  reduction.  As  we  pointed  out  during  the 
discussion  of  failing  filter  condition  validations  (section  3.2.3.3),  when  a  node  n  is  being  re- 
reduced  it  is  expected  that  the  new  reduction  will  supply  all  the  e-conditions  of  n  and  will  con¬ 
sume  all  the  e-preconditions  of  « .  If  the  chosen  schema  instance  does  not  satisfy  these  expec¬ 
tations,  then  the  validation  structure  of  the  plan  has  to  be  re-adjusted.  PRIAR  does  this  by  com¬ 
paring  the  chosen  schema  instance,  5,-,  and  the  e-conditions  and  e-preconditions  of  node  n 
being  reduced,  to  take  care  of  any  validations  that  S,-  does  not  promise  to  preserve.  It  will  (i) 
add  refit  tasks  to  take  care  of  the  e-conditions  of  n  that  are  not  guaranteed  by  S,-,  and  (it) 
prune  parts  of  the  HTN  whose  sole  puipose  is  to  achieve  e-preconditions  of  n  that  are  not 
required  by  5,  . 

An  alternative  way  of  treating  the  failing  filter  condition  validations,  which  would  obviate 
the  need  for  this  type  of  adjustment,  would  be  to  prune  the  e-preconditions  of  n  at  the  time  of 
annotation  verification  itself,  and  add  separate  refit  tasks  to  achieve  each  of  the  e-conditions  of 
n  at  that  time.  However,  this  can  lead  to  wasted  effort  on  two  counts: 

(1)  Some  of  the  e-preconditions  of  n  might  actually  be  required  by  any  new  reduction  of  n, 
and  thus  the  planner  might  wind  up  reachieving  them  during  refitting,  after  first  pruning 
them  all  during  annotation  verification. 

(2)  Some  of  the  e-conditions  of  n  might  be  promised  by  any  alternate  reduction  of  n,  and 
thus  adding  separate  refit  tasks  to  take  care  of  them  would  add  unnecessary  overhead  of 
reducing  the  extra  refit  tasks. 

In  contrast,  the  only  possible  wasted  effort  in  the  way  priar  treats  the  failing  filter  condition 
validations  is  that  the  annotation  verification  procedure  might  be  adding  refit  tasks  to  achieve 
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validations  (say  to  support  the  conditions  of  the  pans  of  the  plan  which  provide  c- 
preconditions  to  the  replaced  reduction)  that  might  evennially  be  pruned  away  during  this  latter 
adjustment. 

3.3.1.  Example 

Figure  9  shows  the  hierarchical  task  reduction  structure  of  the  plan  for  the  S5BS1  problem  that 
PRIAR  produces  by  reducing  the  annotation-verified  task  network  (shown  in  Figure  8).  (The 
top  down  hierarchical  reductions  are  shown  in  left  to  right  fashion  in  the  figure.  The  dashed 
arrows  show  the  temporal  precedence  relations  developed  between  the  nodes  of  the  HTN.)  The 
shaded  nodes  in  the  figure  correspond  to  the  parts  of  the  interpreted  plan  R'  that  survive  after 
the  annotation  verification  and  refitting  process,  while  the  white  nodes  represent  the  refit  tasks 
added  during  the  annotation  verification  process,  and  their  subsequent  reductions. 

During  refitting,  the  planner  reduces  the  refit  task  Ac.tievelClear(l)]  by  putting  K  on 
Table ,  realizing  that  even  though  putting  K  on  I  looks  locally  optimal,  it  causes  more  distur¬ 
bance  to  the  validation  structure  of  R“  (see  below).  The  extra  goal  refit  task 
Achieve  [Clear  (M)]  is  reduced  by  putting  L  on  K;  and  this  decision  leads  to  the  achievement 
of  the  other  extra  goal  refit  task  Achieve  [On  (LJC)]  as  a  side-effect.  As  K  is  on  Table  by  this 
point,  the  planner  finds  that  the  replace  reduction  refit  task  Do[Puton(K  J)]  can  after  all  be 
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Figure  9.  The  plan  produced  by  PRIAR  for  3BS-»S5BS1 
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reduced  by  another  instantiation  of  the  same  schema  that  was  used  to  reduce  it  previously'®. 

3.4.  Issues  of  Control 

In  this  section  we  will  briefly  address  the  issues  of  control  in  PRIAR’s  plan  modification  pro¬ 
cess.  The  purpose  is  to  explain  the  role  played  by  the  plan  validation  structure  in  controlling 
refitting  and  retrieval.  For  the  detailed  development  of  these  control  strategics,  the  reader  is 
referred  to  (15, 17, 13]. 

3.4.1.  Conservative  Control  of  Refitting 

To  derive  maximum  benefits  from  modification  and  reuse,  and  to  prevent  the  possibility  of  the 
refitting  process  degenerating  into  fiom-scratch  planning,  care  must  be  taken  to  ensure  that  the 
reduction  of  the  refit  tasks  would  cause  minimum  distutbance  to  the  parts  of  the  plan  that  are 
already  applicable  in  the  new  situation.  PRIAR  exploits  the  annotated  validation  structure  of  the 
plan  to  estimate  the  disturbance  caused  by  the  reductions  of  refit-tasks  to  the  rest  of  the  plan, 
and  uses  this  estimate  to  select  among  the  schema  instance  choices  for  reducing  tlie  refit  tasks. 

To  estimate  the  disturbance  caused  by  individual  task  reduction  choices,  priar  develops 
the  notion  of  the  task  kernel  of  a  refit  task.  The  task  kernel  encapsulates  the  set  of  validations 
that  have  to  be  preserved  by  any  reduction  of  that  node  to  leave  the  validation  structure  of  R“ 
undisturbed;  it  is  defined  in  terms  of  the  node  annotations.  The  reduction  choices  are  ranked 
by  the  degree  to  which  their  applicability  conditions  and  effects  preserve  the  validations  of  the 
task  kernel  of  the  refit  task.  In  the  3BS-»S5BS1  example  above,  this  control  strategy  recom¬ 
mends  that  the  planner  reduce  the  refit  task  A  [Clear  {I )]  by  putting  K  on  Table  rather  than  on 
L,  M,  ox  J  (even  though  the  last  choice  would  appear  locally  optimal  as  it  achieves  the  extra 
goal  On(JCJ)  "),  because  this  causes  the  least  amount  of  distutbance  to  the  validation  struc¬ 
ture  of  Similarly,  for  the  refit  task  Ac}ueve[Clear{M)],  the  control  strategy  recommends 
reduction  by  putting  L  ox\  K  rather  than  on  Table,  the  other  available  choice.  This  allows  it  to 
achieve  the  second  extra  goal  refit  task  as  a  side  effect.  A  detailed  description  of  this  control 
strategy  is  beyond  the  scope  of  this  paper,  and  can  be  found  in  [IS,  13]. 

3.4.2.  Controlling  Mapping 

While  mapping  is  not  a  serious  problem  if  the  current  plan  itself  is  being  modified  due  to  some 
change  in  the  specification,  it  becomes  an  important  consideration  in  the  case  of  modification 
during  plan  reuse.  There  are  typically  several  semantically  consistent  mappings  between 
objects  of  the  two  planning  situations,  P*’  and  F" ,  and  the  selection  of  the  tight  mapping  could 

If  the  planner  chooses  to  reduce  this  refit  task  in  the  beginning,  then  it  would  have  bound  the  location  of  K 
is  on  /  at  that  time.  Then,  since  the  location  of  K  changes  during  the  planning,  the  task  would  have  to  be  re¬ 
reduced.  Such  a  re-reduction  should  not  be  surprising  as  it  is  a  natural  consequence  of  hierarchical  promiscuity  al¬ 
lowed  in  most  traditiorud  hierarchical  planners  (see  (36]  for  a  discussion). 

This  locally  inoptimal  choice  is  the  characterisdc  of  the  sussman  anomaly.  Putting  JiT  on  7  at  this  juncture 
would  lead  to  backtracking,  as  it  affects  the  executability  of  the  Piiton(J J)  action. 
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considerably  reduce  the  cost  of  modifying  the  chosen  plan  to  conform  to  the  constraints  of  the 
new  problem.  To  do  such  selection,  the  matching  metric  should  be  able  to  estimate  the 
expected  cost  of  modifying  to  solve  P" .  In  priar  modification  framework,  the  cost  of 
refitting  R°  to  P"  can  be  estimated  by  analyzing  the  degree  of  match  between  the  validations 
of  R°  and  the  specification  of  P",  for  various  mappings  {a, ).  We  have  developed  a  heuristic 
ordering  strategy  which  ranks  the  different  mappings  based  on  the  number  and  the  type  of  vali¬ 
dations  of  the  old  plan  that  arc  dependent  on  the  input  state  and  goal  slate  features  of  the  old 
planning  situation,  which  wiU  be  preserved  in  the  new  problem  situation.  The  rationale  behind 
this  heuristic — that  the  cost  of  refitting  depends  both  on  the  number  and  type  of  validations  of 
the  old  plan  that  have  to  be  re-established  in  the  problem  situation — should  be  intuitively  obvi¬ 
ous  given  our  discussion  of  aimotation  verification.  In  our  example,  this  strategy  allows  PRIAR 
to  choose  the  mapping  [A-*L  ,B  -^K  ,C  -iJ]  over  the  mapping  while 

reusing  the  3BS  plan  to  solve  the  S5BS1  problem.  In  is  instructive  to  note  that  while  this  stra¬ 
tegy  is  used  to  choose  between  two  reuse  candidates  corresponding  to  the  same  plan  with 
different  mappings  in  the  current  example,  in  general  the  strategy  can  also  choose  between 
reuse  candidates  using  different  plans.  By  basing  retrieval  on  the  appropriateness  of  using  the 
old  plan  in  the  new  problem  situation,  this  strategy  strikes  a  balance  between  purely  syntactic 
feature-based  retrieval  methods,  and  methods  which  require  a  comparison  of  the  solutions  of 
the  new  and  old  problems  to  guide  the  retrieval  (e.g.  [2]).  Further  details  of  this  retrieval  and 
mapping  strategy  can  be  found  in  [17, 13], 

4.  Analysis  and  Evaluation  of  PRIAR 

4.1.  Empirical  Evaluation 

The  PRIAR  modification  framework  described  in  this  paper  has  been  completely  imple¬ 
mented  in  COMMON  LISP  and  runs  as  compiled  code  on  a  Texas  Instruments  EXPLORER-n  Lisp 
Machine.  The  hierarchical  planner  used  in  priar  is  a  reimplemented  version  of  NONUN 
[30,7].  Performance  evaluation  experiments  were  conducted  in  an  extended  blocks  world 
domain  (see  Appendix  B  for  the  domain  specification)  to  quantify  the  savings  in  planning 
effort  afforded  by  the  modification  framework,  (priar  is  also  being  adapted  to  provide  an 
incremental  planning  capability  for  process  planning  in  concurrent  engineering  environments.  A 
prototype  version  is  currently  operational;  see  [21]  for  details.)  The  evaluation  experiments 
consisted  of  solving  several  blocks  world  problems  by  reusing  a  range  of  similar  to  dissimilar 
stored  plans.  In  each  experiment,  statistics  were  collected  for  solving  the  new  problem  from 
scratch  and  for  solving  it  by  modifying  a  given  plan.  A  comprehensive  listing  of  these  statis¬ 
tics  can  be  found  in  [13]. 

The  cost  of  retrieval  was  factored  out  in  all  these  experiments  by  providing  priar  with  a 
specific  existing  plan  7?"  to  be  reused  while  solving  the  new  problem  P".  However,  the 
appropriate  mapping,  ot,  between  R°  and  P"  is  still  chosen  by  the  retrieval  procedure.  Such  a 
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testing  strategy  is  motivated  by  our  desire  to  measure  the  flexibility  of  the  modification  frame¬ 
work  by  forcing  PRIAr  to  solve  P"  by  reusing  different  R°  *s. 

Tlic  problems  used  in  these  experiments  are  all  from  the  blocks  world.  Problems  3BS, 
4BS.  6BS,  8BS  etc.  arc  block  stacking  problems  with  three,  four,  six,  eight,  etc.  blocks  rc.spcc- 
tivcly  on  the  table  in  the  initial  state,  and  stacked  on  top  of  each  other  in  the  final  state.  Prob¬ 
lems  dDdl,  5BS1,  6BS1  etc.  correspond  to  blocks  world  problems  where  all  the  blocks  are  in 
sf’.nc  arbitrary  configuration  in  the  initial  state,  and  stacked  in  some  order  in  the  goal-state.  In 
particular,  S5BS1  corresponds  to  the  example  that  we  discussed  in  the  previous  sections.  A 
complete  lisdng  of  the  test  problem  specifications  can  be  found  in  [13]. 

Table  1  presents  representative  statistics  firom  the  experiments.  It  compares  planning 
times  (measured  in  epu  seconds),  the  number  of  task  reductions,  and  the  number  of  detected 
interactions,  for  from-scratch  planning  and  for  planning  with  reuse,  in  some  representative 
experiments.  The  second  entry  in  Table  I  corresponds  to  the  3BS-45SBS1  example  discussed 
in  the  previous  sections.  The  last  column  of  the  table  presents  the  computational  savings 
gained  through  reuse  as  compared  to  from-scratch  planning  (as  a  percentage  of  the  from 


P" 

P"  From  Scratch 

Reuse  R" 

Savings 

(%) 

3BS^4BS1 

(  4.0j.  12/1,  5i  J 

(  2.4s,  4/1,  1/  ] 

39 

3BS->S5BSI 

[  12.4s,  17/r,  22/  ] 

[  5.2s.  Bn,  12/  ] 

58 

5BS->7BS1 

[  38.6J,  24/».  13/] 

[  ll.ls,  I2n,  19/  ] 

71 

4BS1-^8BS1 

(  79-3s,  28n,  14/] 

(  22.2s.  18/1,  18/  ] 

71 

5BS^8BS1 

[  79-3s,  28n.  14/] 

[  lO.ls,  14n,  7/  ] 

87 

6BS-»9BS1 

[  184.fo.  32n,  17/  ] 

[  18.1s.  17/1,  17/  ] 

90 

10BS-»9BS1 

[  184.6s.  32n.  17/  ] 

(  6Ss,  S/I,  2/  ] 

96 

4BS-410BS1 

[  401,Ss.  36n.  19/  ] 

[  52.9s.  30/1,  33/  ] 

86 

8BS-»10BS1 

[  401,Ss,  36/r,  19/  ] 

[  14.5s,  12/1,  7/  ] 

96 

3BS-»12BS1 

(  1758.6s,  44/1,  23/  ] 

[  77.1s.  40/1,  38/] 

95 

5BS^12BS1 

[  17S8.6S.  44/1,  23/  ] 

[  51.84,32/1,26/] 

97 

10BS-^12BS1 

[  17S8.ds,  44/1,  23/  ] 

[  21,2s,  13n,  7/] 

98 

Table  1.  Sample  statistics  for  priar  reuse 
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scratch  planning  time). 

The  entries  in  the  table  show  that  the  overall  planning  times  as  well  as  tlic  number  of 
task  reductions  improve  significantly  with  reuse.  Tliis  confirms  that  reuse  and  modification  in 
the  PRlAR  framework  can  lead  to  substantial  savings  over  generative  planning  alone.  The  rela¬ 
tive  savings  over  the  entire  corpus  of  (approximately  70  )  experiments  ranged  from  30%  to 
98%  (corresponding  to  speedup  factors  of  1.5  to  50).  with  the  highest  gains  shown  for  the 
more  difficult  problems  tested.  The  average  relative  savings  over  the  entire  corpus  was  79%’^. 

We  also  analyzed  the  variation  in  the  savings  accrued  by  reuse  in  terms  of  the  similarity 
between  the  problems  and  the  size  of  the  constructed  plans.  Figure  10  shows  the  plot  of  this 
variation.  It  plot  shows  tlic  computational  savings  achieved  when  different  blocks  world  prob¬ 
lems  arc  solved  by  reusing  a  range  of  existing  blocks  world  plans.  For  example,  the  curve 
marked  7BS1  shows  the  .savings  afforded  by  solving  a  particular  seven-block  problem  by  reus¬ 
ing  several  different  blocks  world  plans  (shown  on  the  x  -axis).  Figure  1 1  summarizes  all  the 
individual  variations  by  plotting  (in  logarithmic  scale)  the  from-scratch  plaruiing  time,  and  the 
best  and  worst  case  reuse  planning  times  observed  for  the  set  of  blocks  world  problems  used  in 
our  experiments.  It  shows  an  observed  speedup  of  one  to  two  orders  of  magnitude. 

Apart  from  the  obvious  improvement  in  reuse  performance  with  respect  to  similarity 
between  F"  and  P",  these  plots  bring  out  two  other  interesting  characteristics  of  the  PRlAR 


Figure  10.  Variatioii  of  performance  with  problem  size  and  similarity 


The  cumulative  savings  were  much  higher,  but  they  are  biased  by  the  higher  gains  of  the  more  difficult 
problems. 
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reuse  behavior; 

1.  Flexibility  and  Conservatism  of  Modiheation: 

As  we  pointed  out  earlier,  a  flexible  and  conservative  modification  strategy  provides  the 
capability  to  effectively  reuse  any  applicable  parts  of  a  panially  relevant  plan  in  solving  a 
new  planriing  problem.  An  important  characteristic  of  such  a  modification  strategy  is  that 
is  that  as  the  size  of  /*"  increasc.s,  the  computational  savings  afforded  by  FRUR  stay  very 
high  for  a  wide  range  of  reused  plans  with  varying  similarity.  This  behavior  is  brought 
out  by  the  plots  in  Figures  10  and  II.  Consider,  for  example,  the  plot  for  the  12B31  in 
Figure  10.  As  we  go  from  a  dissimilar  plan  R°  ss  3BS  to  a  very  similar  plan  R"  =  9BS, 
the  savings  vary  between  95%  and  98%  (corresponding  to  a  variation  in  the  speedup  fac¬ 
tor  of  20  to  50).  One  of  the  important  benefits  of  a  flexible  reuse  framework  is  that  the 
best  match  retrieval  may  not  be  critical  for  the  utility  of  plan  reuse.  This  may  allow  the 
use  of  simple  and  computationally  efficient  retrieval  strategics  (17]. 

2.  Performance  improvement  with  respect  to  the  size  of  the  planning  problem: 

An  interesting  pattern  observed  in  PRlAR’s  performance  is  that  when  it  modifies  the  same 
plan  R^  io  solve  several  different  problems,  the  computational  savings  increase  with  the 
size  of  the  problem  being  solved.  Consider  for  example  the  cases  of  3BS-»7BS1  vs. 
3BS->12BS1  in  Figure  10.  The  improvement  with  size  is  further  characterized  by  the 
statistics  in  Table  2,  which  lists  the  performance  statistics  when  the  3BS  plan  is  used  to 
solve  a  set  of  increasingly  complex  blocks  world  problems.  This  can  be  explained  in 


Figure  11.  From-scratch  vs.  best  and  worst  case  reuse  performance 
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R"  -»  P" 

P"  From  Scratch 

(epu  sec.) 

Reuse  R” 

(epu  see.) 

Savings 

(%)  speedup  j 

3BS-»4BS1 

4.0 

2.4 

39 

1.6 

3BS-»5BS1 

8.4 

mm 

3BS->7BS1 

38.6 

15.6 

59 

3BS-»8BS1 

79.3 

17.4 

78 

4.6 

3BS-riOBSl 

401.5 

71.4 

86 

5.6 

3BS-»12BS1 

1758.6 

11. \ 

95 

22.8 

Table  2.  Variation  of  reuse  performance  svith  problem  size 

terms  of  the  search  process  in  the  space  of  the  plans.  In  hierarchical  planning,  as  the  size 
of  a  planning  problem  increases,  the  effective  branching  factor  of  the  search  space  also 
increases.  For  example,  for  a  g  goal  problem,  where  the  average  number  of  choices  for 
reducing  a  goal  in  the  domain  is  T,  the  branching  factor  at  the  first  level  will  be  propor¬ 
tional  to  i.e.,  the  branching  factor  increases  with  If  3  is  the  branching  factor 
of  the  search  space,  A  is  the  operator  distance  between  the  problem  specification  P"  and 
the  plan  R",  and  A'  is  the  operator  distance  between  the  R“  and  P",  then  wc  can  quan¬ 
tify  the  relative  reduction  in  the  explored  search  space  during  plan  reuse  as  (23, 13]. 
Thus,  as  P  increases,  so  will  the  relative  reduction  in  the  search  space.  Thus,  as  problem 
size  increases,  the  savings  afforded  by  reuse  tend  to  become  more  significant. 

4.2.  Analysis 

In  this  section  we  shall  analyze  the  completeness,  coverage,  flexibility  and  efficiency  of  the 
PRIAR  framework. 

4.2.1.  Completeness 

To  demonstrate  completeness,  we  must  show  that  priar  can  solve  any  new  planning  problem 
by  correctly  modifying  any  plan,  whose  validation  stiucnire  is  describable  within  its  representa¬ 
tion  language.  If  we  assume  that  the  underlying  planning  strategy  is  complete,  the  complete¬ 
ness  of  PRIAR  can  be  established  by  demonstrating  that  for  any  given  plan  R°  and  a  new 

Another  way  of  understanding  this  is  that  as  the  size  of  the  the  planning  problem  inaeases,  the  number  of 
ways  of  interpreting  the  modal  truth  criterion  to  achieve  a  goal  (in  Chinan’s  model  of  ixmliitear  planning  [3]) 
also  increases. 
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problem  P" ,  TRIAR  provides  an  irTN  with  a  consistent  validation  structure  to  the  planner.  Tlie 
validation  stnrcturc  based  modification  is  complete,  in  thiat  it  will  correctly  handle  all  tjpes  of 
applicability  failums  Uiat  may  ari.se  during  plan  modification,  and  provide  the  planner  with  a 
partially  reduced  HTN  witli  a  consistent  validation  structure.  In  particular,  our  definition  of 
inconsistencies  (see  §2.2)  captures  all  types  of  applicability  failures  that  can  arise  due  to  a 
change  in  the  .specification  of  the  problem;  and  our  annotation  verification  procedure  provides 
methods  to  cotTccily  modify  the  plan  validation  structure  to  handle  each  type  of  inconsistency 
(see  section  3.2). 

Proposition:  The  HTN  at  the  end  of  the  Annotation-verification  procedure  is 
a  partially  reduced  plan  with  a  consistent  validation  structure. 

Wlien  a  plan  is  being  reused  in  a  new  problem  situation,  the  inconsistencies  in  the  validation 
structure  originate  from  the  differences  in  the  initial  and  final  state  specification:  the  interpreta¬ 
tion  procedure  marks  these  differcnees.  The  overall  plan  can  be  seen  as  a  black-box,  v/hich 
consumes  the  validations  in  the  initial  validation  state  and  supplies  the  validations  in 

the  final  validation  state  A'’{ni).  Titus  the  only  way  the  differenacs  in  the  problem 
specifications  can  cause  inconsistencies  in  the  validation  structure  of  the  plan  is  by  affecting 
the  validations  in  and  Thus,  the  arinotation-vcrification  procedure  would 

only  have  to  check  these  validations. 

The  only  ways  in  which  the  validations  of  A’(nf)  and  A^in^)  can  be  affected  by  the 
changes  in  the  problem  specifications  arc;  (/)  some  validations  of  A*(ni)  fail  because  of  the 
disappearance  of  their  supporting  effects,  (ii)  some  validations  of  A'^irtc}  are  not  required 
because  they  are  supporting  unnecessary  goals  and  finally  {Hi)  some  goals  of  the  new  problem 
are  not  supported  by  any  validations  of  i4'’ («<;).  These  are  precisely  the  cases  that  are  defined 
as  the  inconsistencies  in  the  validation  stnicture  of  a  plan  (in  section  2.1).  We  have  seen  that 
the  annotation-verification  process  modifies  the  plan  validation  structure  to  take  care  of  each  of 
these  three  possibilities,  and  also  to  exploit  any  serendipitous  effects.  The  repair  actions 
involve  either  removing  some  parts  of  the  plan,  or  adding  high  level  non-primitive  tasks  to  the 
plan  to  re-establish  missing  or  failing  validations.  To  prove  that  the  resulting  partially  reduced 
HTN  has  a  consistent  validation  structure,  we  need  only  show  that  the  repair  actions  themselves 
do  not  introduce  any  inconsistencies. 

There  are  three  kinds  of  changes  made  to  the  validation  structure  of  R'  during  these 
repair  tasks:  (f)  some  existing  validations  are  removed,  («)  some  existing  validations  are  re¬ 
directed,  or  (Hi)  some  new  validations  are  added.  We  can  easily  show  that  priar’s  methods  for 
removal  of  unnecessaiy  validations,  and  redirecting  validations  (to  the  ancestors  of  the  source 

Of  course,  while  Uking  care  of  some  of  the  affected  validations,  the  annotation  verification  procedure  might 
prune  or  redirect  some  iniemal  validations  of  the  plan  (see  the  procedures  for  pruning  validations  and  repairing  fail¬ 
ing  filter  condition  validations). 
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or  destination  nodes)  do  not  introduce  any  new  inconsistencies.  Thus  the  only  remaining  case 
is  the  addition  of  a  new  validation.  Here  too,  there  are  two  possibilities: 

(1)  When  a  failing  precondition  validation  v  :(E  ,ni  ,C  ,nj)  is  repaired  by  adding  a  new  valida¬ 
tion,  V,  C,nd),  such  that  ni<nr<nd.  In  this  case,  the  only  possible  inconsistency 
could  be  failure  of  v,.  For  to  faU,  there  should  exist  a  node  n  such  that  ^  (nr<n<n^) 

and  effectsin)  1 - £.  Since,  ni<nr<n^  (see  section  3.2.3.1),  this  will  also  imply  that 

l^{n,<n<nf).  That  is,  v  itself  could  not  have  been  established.  Since  v  was  established 
previously,  by  refutation  we  know  that  v,  cannot  be  failing. 

(2)  When  completely  new  validations  are  introduced  into  HTN  to  take  care  of  missing  valida¬ 
tions  or  p  -phantom-validations.  In  these  two  cases,  we  have  seen  that  the  repair  actions 
invoke  the  planner’s  truth  criterion  to  make  sure  that  the  new  validation  does  not  lead  to 
the  failure  of  any  existing  validations. 

Thus,  all  the  repair  actions  remove  the  inconsistencies  in  /?',  without  adding  any  new  incon¬ 
sistencies.  Consequently,  the  HTN  after  annotation  verification,  ,  has  a  consistent  validation 
structure.D 

To  summarize,  the  annotation-verification  based  reuse  framework  presented  here  is  com¬ 
plete  in  the  sense  that  if  P"  is  a  problem  that  PRiAR’s  planner  can  solve  from  scratch,  then 
PRIAR  can  take  any  arbitrary  previously  developed  plan,  R°,  a  new  problem  P"  and  provide 
P®  which  can  then  be  reduced  by  the  planner  to  give  a  plan  for  P".  This  is  because  we  are 
able  to  list  with  certainty  all  the  possible  inconsistencies  that  can  arise  in  the  validation  struc¬ 
ture  of  a  plan  during  reuse  and  provides  methods  to  remove  the  inconsistencies  without  intro¬ 
ducing  any  new  inconsistencies. 

Notice,  however,  that  while  the  consistency  of  annotation-verified  plan  R‘‘  aUows  the 
planner  to  try  to  solve  for  P"  by  reducing  R“  rather  than  starting  from  scratch,  it  cannot  by 
itself  ensure  that  a  plan  for  P"  can  be  found  without  backtracking  over  P".  For  this  latter  pro¬ 
perty  to  hold,  the  abstraction  used  in  the  task  reduction  schemas  representing  the  domain 
should  have  the  "downward  solution”  property  [31]  where  the  existence  of  an  abstract  plan 
implies  the  existetice  of  specializations  of  this  solutions  at  each  lower  level  (see  below). 

4.2.2.  Coverage 

Here  we  discuss  how  well  the  modification  capability  provided  by  our  theory  covers  the  range 
of  possible  plan  modification  tasks.  The  validation  structure  developed  here  covers  the  internal 
dependencies  of  the  plans  produced  by  most  traditional  hierarchical  plaimers.  The  captured 
dependencies  can  be  seen  as  a  form  of  explanation  of  correctness  of  the  plan  with  respect  to 
the  planner’s  own  domain  model.  By  ensuring  the  consistency  of  the  validation  structure  of  the 
modified  plan,  priar  guarantees  correctness  of  the  modified  plan  with  respect  to  the  plarmer. 
However,  it  should  be  noted  that  as  the  dependencies  captured  by  the  validation  structure  do 
not  represent  any  optimality  considerations  underlying  the  plan,  the  optimality  of  modification 
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is  not  guaranteed.  Further,  since  the  modification  is  integrated  with  the  planner,  failures  arising 
from  the  incorrectness  or  incompleteness  of  the  planner’s  own  domain  model  will  not  be 
detected  or  handled  by  the  modification  theory*^  [18].  Of  course,  these  should  not  be  con¬ 
strued  as  limitations  of  the  theory,  as  the  goal  of  the  theory  is  to  improve  the  average  case 
efficiency  of  the  planner. 

4.2.3.  Flexibility  and  Efficiency 

Computational  savings  in  modifying  plans  in  the  PRIAR  framewoik  stem  from  the  fact  that  the 
annotation  verification  process  expends  a  polynomial  amount  of  processing  on  to  produce  a 
partially  reduced  HTN,  /?“,  which  can,  on  the  average,  be  reduced  with  exponentially  less  effort 
compared  to  planning  for  P"  from  scratch.  While  we  cannot  expect  a  reduction  in  the 
theoretical  complexity  of  planning  unless  the  domain  schemas  have  the  “downward  solution 
property”  (see  above),  typically  there  is  a  strong  performance  improvement  by  starting  the 
planner  off  with  R“ .  The  empirical  results  discussed  in  section  4,2.1.  provide  support  to  this. 

PRIAR  reuse  strategy  is  flexible  in  that  it  can  effectively  modify  any  existing  plan  to  solve 
any  new  problem.  Flexibility,  however,  is  a  double-edged  sword — while  it  improves  the  cov¬ 
erage  of  the  modification  strategy  by  allowing  a  plan  to  be  reused  in  a  wide  variety  of  new 
situations,  it  also  leads  to  situations  where  the  plan  is  reused  in  a  totally  inapplicable  situation. 
In  PRIAR,  however,  this  does  not  pose  a  serious  problem  because  the  annotation  verification 
procedure  is  of  polynomial  complexity.  In  the  worst  case,  when  none  of  the  steps  of  are 
applicable  in  the  new  situation,  annotation  verification  will  return  a  degenerate  HTN  containing 
refit  tasks  for  all  the  goals  of  P" .  In  such  extreme  cases  priar  may  wind  up  doing  a  polyno¬ 
mial  amount  of  extra  work  compared  to  a  pure  generative  planner.*®  In  other  words,  the  worst 
case  complexity  of  plan  modification  remains  the  same  as  the  worst  case  complexity  of  genera¬ 
tive  planning.  However,  on  the  average,  PRIAR  wiU  be  able  to  minimize  the  repetition  of  plan¬ 
ning  effort  (thereby  accruing  possibly  exponential  savings  in  planning  time)  by  providing  the 
planner  with  a  partially  reduced  HTN  that  contains  all  the  applicable  parts  of  the  plan  being 
modified,  and  conservatively  controlling  refitting  such  that  the  already  reduced  (applicable) 
parts  of  are  left  undisturbed.  The  claims  of  flexibility  and  average  case  efficiency  are  also 
supported  by  the  empirical  evaluation  experiments  that  were  conducted  on  PRIAR,  as  discussed 
in  section  4.1. 


In  [19]  we  discuss  some  preliminary  ideas  about  dealing  with  failure  of  validations  established  by  modules 
external  to  the  planner. 

It  should  also  be  noted  that  the  mining  and  retrieval  strategy  developed  in  [17, 13]  helps  in  ruling  out  such 
degenerate  cases  to  a  large  extent. 


5.  Comparison  to  Previous  Work 

Early  research  in  plan  reuse  and  replanning  was  done  in  conjunction  with  the  woiic  on  STRIPS 
plarmer  [6].  The  strips’  triangle-table  based  approach  to  replanning  suffered  from  many  limi¬ 
tations.  As  we  pointed  out  in  section  1,  STRIPS  was  unable  to  modify  the  internal  structure  of 
its  remembered  macro-operators  to  suit  new  problem  situations,  and  consequently  could  reuse 
them  only  when  either  the  entire  macrop  or  one  of  its  subsequences  was  applicable  in  the 
current  situation.  Its  only  response  to  execution  time  failures  was  restarting  the  plan  from  an 
appropriate  previously  executed  step.  Such  a  capability  is  in  general  not  sufficient  to  provide  a 
robust  replaiming  capability,  as  it  is  very  rare  that  the  execution  time  failures  are  so  benign  as 
to  be  repaired  by  restarting  the  plan  from  an  earlier  point.  A  recent  hierarchical  linear  problem 
solver  called  ARGO  [11]  tries  to  partially  overcome  the  inflexibility  of  the  macro-operator  based 
reuse  by  remembering  macro-operators  for  each  level  of  its  hierarchical  plan.  However,  it  too 
lacks  the  capability  to  modify  the  intermediate  steps  of  a  chosen  macro-operator,  and  is  conse¬ 
quently  unable  to  reuse  all  the  applicable  portions  of  a  plan. 

Hayes  [9]  was  the  first  to  suggest  the  idea  of  explicitly  represented  internal  dependencies 
for  guiding  replarming.  However,  his  framework  was  very  domain-specific  and  the  only 
replanning  action  allowed  in  it  was  to  delete  a  part  of  a  plan,  thereby  permitting  the  planner  to 
reachieve  some  higher  level  goals  in  the  hierarchical  development  of  the  plan.  NONUN  [30,29] 
was  the  first  hierarchical  planner  to  advocate  explicit  representation  of  goal  dependencies  to 
guide  planning.  Its  GOST  data  structure  is  essentially  a  list  of  protection  intervals  associated 
with  the  plan,  and  is  used  during  the  planning  to  guide  the  interaction  detection  and  resolution. 
Daniel  [5]  exploited  NONUN’s  plan  structure  to  develop  a  framewoik  for  representing  decision 
dependencies  to  aid  in  backtracking  during  planning.  The  intent  was  to  enable  nonun  to  do 
dependency  directed  backtracking  during  plan  generation  While  Daniel’s  research  did  not 
explicitly  consider  replanning  or  reuse  problems,  it  generalized  Hayes’  notion  of  decision 
graphs  significantly  to  capture  inter-decision  dependencies  induced  by  NONUN.  However,  here 
again,  the  development  was  very  planner  specific.  There  was  neither  a  formal  characterization 
of  the  remembered  dependencies,  nor  a  systematic  exploration  of  their  utility  in  plan 
modification.  Recently,  Morris  et  al  [24]  started  exploring  the  utility  of  TMS-ba.sed  data 
dependency  methods  for  representing  these  decision-graph  structures  to  provide  a  dependency- 
directed  backtracking  capability  during  planning.  In  the  following  we  discuss  the  relation 
between  PRlAR  modification  framewoik  and  these  data  dependency  methods: 

Any  dependency  directed  plan  transformation  scheme  must  be  able  to  handle  the  follow¬ 
ing  three  distinct  issues:  (/)  What  choice  points  would  have  to  be  revoked  to  handle  the  change 
in  the  specification  or  the  environment,  («)  How  to  effectively  retract  the  decisions  that  were 
made  in  the  context  of  those  choice  points,  and  (iii)  How  best  to  guide  the  planning  after  the 
retraction,  to  satisfy  the  overall  goals.  While  decision  graphs,  context  layered  world-models 
[34]  and  TMS  based  data  dependency  frameworks  provide  strategies  for  handling  it,  they  do 
not  provide  guidance  on  i  and  iii.  In  contrast,  we  have  shown  that  the  explicit  planner- 
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independent  representation  of  tlie  causal  dependencies  of  a  plan  (as  its  validtaion  structure)  pro¬ 
vides  a  powerful  medium  for  deliberating  on  what  types  of  modifications  are  required  and  how 
to  guide  the  planner  in  carrying  out  those  modifications. 

Wilkins’  framework  for  guiding  replanning  and  execution  monitoring  in  SIPE  [35]  comes 
closest  to  PRiAR’s  plan  reuse  and  modification  framework  in  its  treatment  of  applicability 
failures.  (For  a  detailed  discussion  of  how  PRIAR’s  modification  framework  is  used  to  guide 
and  control  execution  monitoring  and  replanning,  see  [20J.)  SIPE’s  domain-independent  replan¬ 
ning  actions  are  similar  to  the  repairs  to  the  plan  validation  structure  that  are  suggested  by 
PRiAR’s  annotation- verification  process.  However,  SEPE  does  not  attempt  to  explicitly  character¬ 
ize  the  role  played  by  the  individual  tasks  of  the  HTN  in  the  validation  of  the  rest  of  the  plan. 
Consequently,  some  of  its  replanning  actions  are  planner  dependent,  and  are  not  stated  for¬ 
mally.  In  contrast,  PRiAR’s  annotated  validation  structure  gives  a  clean  framework  to  state  the 
replanning  actions  precisely  and  explicitly.  Another  important  difference  between  the 
modification  strategies  of  PRIAR  and  SIPE  is  that  the  latter  does  not  attempt  to  control  the 
replanning  once  the  appropriate  replanning  actions  were  suggested  to  SIPE.  As  we  discussed 
briefly  in  section  3.4.1  PRIAR  employs  a  heuristic  control  strategy  grounded  in  the  plan  valida¬ 
tion  structure  for  this  purpose. 

In  contrast  to  the  dependency  directed  debugging  strategies  such  as  (27, 8, 28]  which  aim 
to  compensate  for  the  inadequacies  of  the  generative  planner  by  debugging  the  generated  plans, 
PRIAR  aims  to  improve  the  efficiency  of  planning  by  ensuring  the  correctness  of  modification 
with  respect  to  the  planner.  The  plan  debugging  strategies  proposed  in  GORDIUS  and  CHEF  use 
an  explanation  of  the  correctness  of  the  plan  with  respect  to  an  external  (deeper)  domain 
model — generated  through  a  causal  simulation  of  the  plan  to  guide  the  debugging  of  the 
plan — to  compensate  for  the  inadequacies  of  the  planner’s  own  domain  model.  In  contrast,  the 
plan  modification  strategy  proposed  in  PRIAR  utilizes  the  plan  validation  structure,  an  automati¬ 
cally  generated  explanation  of  correctness  of  the  plan  with  respect  to  the  planner’s  own  domain 
model,  to  integrate  planning  and  plan  modification  and  to  ensure  correctness  of  plan  with 
respect  to  the  planner.  Since  the  cost  of  debugging  tends  to  be  very  high*^,  a  fhiitful  avenue 
of  research  might  be  to  combine  these  strategies  such  that  PRiAR’s  strategies  are  used  to 
efficiently  generate  plans  that  are  correct  with  respect  to  the  planner,  and  the  debugging  stra¬ 
tegies  are  used  to  test  and  debug  these  plans  with  respect  to  external  domain  models.  In  this 
sense,  PRiAR’s  strategies  are  complementary  to  these  debugging  strategies. 

A  sigruficant  amount  of  research  in  case-based  reasoning  addressed  the  issues  involved  in 
the  adaptation  of  stored  plans  to  new  situations  (e.g.,  [1,8,32]).  In  contrast  to  PRIAR,  typically 
these  modification  strategies  are  not  integrated  with  a  generative  planner,  are  not  concerned 
with  correctness  and  conservatism  of  modification,  and  are  typically  heuristic  in  nature.  This  is 

In  (26],  SiiTunons  notes  that  the  success  of  cORDtUS’s  Generate-Test-Debug  paradigm  rests  on  the  presence 
of  a  robust  generator  since  debugging  is  very  costly. 
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to  a  large  extent  a  reflection  of  the  characteristics  of  the  domains  in  which  these  systems  were 
developed,  where  the  need  to  avoid  execution  time  failures  is  not  as  critical  as  the  need  to  con¬ 
trol  access  to  planning  knowledge.  For  example,  PLEXUS  [1],  an  adaptive  planner,  starts  with  a 
highly  structured  plan  library,  and  relies  on  the  place  of  a  plan  in  the  background  of  otlier 
plans  in  the  library  to  guide  adaptation.  PLEXUS  works  as  an  interpretive  planner,  and  its  pri¬ 
mary  mode  of  detecting  applicability  failures  is  through  execution  time  failures.  When  a 
failure  is  detected,  PLEXUS  attempts  to  exploit  the  helpful  cues  from  the  new  problem  situation 
to  trigger  appropriate  refitting  choices  to  repair  those  applicability  failures,  and  execute  the 
result  in  turn.  Similarly,  CHEF’s  [8]  stored  plans  do  not  have  explicitly  represented  dependency 
structure,  and  they  are  modified  by  domain  dependent  modification  rules  to  make  the  old  plan 
satisfy  all  the  goals  of  a  new  problem.  These  modification  strategies  do  not  consider  the  inter¬ 
nal  causal  dependency  structure  of  the  plan,  and  thus  may  lead  to  incorrect  plans  even  relative 
to  the  domain  knowledge  contained  in  the  case-base  and  the  modifier,  chef  presumes  that  its 
retrieval  strategy  and  modification  rules  are  robust  enough  to  prevent  frequent  occurrence  of 
such  incorrect  plans  (as  we  discussed  above,  CHEF  does  test  the  correctness  of  its  modification 
through  a  simulation  with  respect  to  an  external  domain  model).  In  contrast  to  PLEXUS  and 
CHEF,  PRIAR  is  concerned  with  the  correemess  of  the  modified  plan  relative  to  the  planner’s 
own  domain  knowledge,  and  uses  the  plan  validation  structure  to  ensure  this.  This  capability 
is  important  both  because  debugging  itself  is  a  very  costly  operation  (see  [26, 27])  and  because 
domain  characteristics  may  put  a  very  high  premium  on  postponing  all  debugging  to  the  execu¬ 
tion  time. 

Finally,  PRiAR’s  approach  to  plan  reuse  is  in  the  spirit  of  Carbonell’s  [2]  proposed  metho¬ 
dology  for  “problem  solving  by  derivational  analogy”  which  recommends  remembering  a  full 
derivational  history  along  with  every  problem  solution,  and  using  it  to  guide  its  analogical 
transformation  later.  PRIAR  can  be  seen  as  a  step  towards  the  systematic  exploration  of  the  util¬ 
ity  of  including  one  class  of  informatior. — the  plan  validation  structure — in  the  stored  deriva¬ 
tional  trace. 

6.  Conclusion 

We  presented  a  theory  of  plan  modification  that  utilizes  the  validation  structure  of  the  stored 
plans  to  yield  a  flexible  and  conservative  modification  framework.  The  validation  struchire, 
which  constitutes  a  hierarchical  explanation  of  correctness  of  the  plan  with  respect  to  the 
planner’s  own  knowledge  of  the  domain,  is  aimotated  on  the  plan  as  a  by-product  of  the  initial 
planning.  Plan  modification  is  characterized  as  a  process  of  removing  inconsistencies  in  the 
validation  structure  of  a  plan,  when  it  is  being  reused  in  a  new  (changed)  planning  situatioa 
Annotation  verification,  a  polynomial  time  process,  carries  out  the  repair  of  these  inconsisten¬ 
cies.  The  repairs  involve  removing  unnecessary  parts  of  the  HTN,  adding  new  high-level  usks 
to  it  to  re-establish  failing  validations,  and  exploiting  any  serendipitous  effects  to  shorten  the 
plan.  The  resultant  partially  reduced  HTN  with  a  consistent  validation  structure  is  given  to  the 
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planner  for  complete  reduction.  As  the  planner  starts  with  a  partially  reduced  HTN,  it  takes 
significantly  less  time  on  the  average  to  produce  a  complete  plan.  This  is  supported  by  the 
results  of  tlie  empirical  studies  in  blocks  world,  which  demonstrated  20-98%  savings 
(corresponding  to  speedup  factors  of  1.5  to  50)  over  pure  generative  planning,  with  the  highest 
gains  shown  for  the  most  complex  problems  tested. 

We  discussed  the  development  of  this  theory  in  PRIAR,  and  characterized  its  complete¬ 
ness,  coverage,  efficiency  and  limitations.  PRIAR’s  modification  theory  enables  a  plaimer  to 
conserv'atively  modify  its  plan  in  response  to  incremental  changes  in  the  specification,  to  reuse 
its  existing  plans  in  new  problem  situations,  and  to  efficiently  replan  in  response  to  execution 
time  failures.  While  the  plans  made  by  PRIAR  are  at  the  same  level  of  correemess  as  the  ones 
that  are  made  by  the  planner  from  scratch,  in  practical  terms,  PRIAR  allows  the  planner  to  solve 
more  problems  in  a  “reasonable  amount”  of  time  and  computational  resources.  This  is  very 
significant,  since  it  enlarges  the  set  of  problems  that  arc  practically  solvable  by  the  planner. 
Currently,  we  are  exploring  the  application  of  PRIAR  modification  strategy  to  more  realistic 
domains  [21],  and  investigating  the  methodology  of  plan  modification  in  complex  domains 
where  the  planner  does  not  have  access  to  all  the  domain  knowledge  and  has  to  interact  with 
other  specialized  domain  modules  [19]. 

Acknowledgements 

Lindley  Darden  and  Larry  Davis  have  significantly  influenced  the  development  of  this  work. 
Jack  Mostow  and  Austin  Tate  provided  useful  comments  on  previous  drafts.  Marie  Drummond, 
David  Wilkins,  Nils  Nilsson,  Marty  Tenenbaum,  Quiang  Yang  and  reviewers  of  AAAI-90  and 
IJCAI-89  provided  several  useful  and  pointers.  To  all,  our  thanks. 


40 


r 


Appendix  A.  Trace  output  by  PRIAR 

This  appendix  contains  an  annotated  trace  of  the  PRIAR  program  as  it  plans  for  a  blocks 
world  problem  by  reusing  an  existing  plan.  Specifically,  it  follows  PRIAR  in  solving  the  5BP 
problem  shown  on  the  right  in  Figure  A.l  by  reusing  an  existing  plan  for  solving  the  6BS 
problem  shown  on  the  left.  This  example  is  specifically  designed  to  show  how  priar  handles 
the  failing  filler  condition  validations,  unnecessary  validations  and  p  -phantom  validations  (the 
capabilities  that  were  not  brought  out  in  the  example  that  was  discussed  in  the  paper). 

In  this  example,  PRIAr’s  partial  unification  procedure  generates  two  plausible  reuse  candi¬ 
dates  for  solving  the  5BP  pioblem  from  the  6BS  plan  Oines  1-11).  The  plan  kernel  based  ord¬ 
ering  then  prefers  one  of  those  candidates  (6BS,  oa=[A-*L,C-*0 ^-*P  J)-*M as 
better  suited  for  solving  the  5BP  problem  Oines  13-19). 
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Figure  A.l.  6BS->5BP  Modification  problem 


1  PRIAR>  rptoblem  *5b*-ph»morf»-pyi»nu<l  ocuie  t) 

2  Trying  to  solve  the  problem  by  reusing  old  plans 

3  Calling... 

4  (REUSE-PLAN  <X)ALS  ((ON  P  O)  (ON  M  N)  (ON  L  P)  (ON  O  M)) 

5  JNPUT  ((BLOCK  P)  (CLEARTOP  O)  (ON  O  P)  (ON  L  TABLE) 

6  (ON  P  TABLE)  (BLOCK  O)  (BLOCK  N)  (BLOCK  M) 

7  (PYRAMID  L)  (CLEARTOP  M)  (ON  M  N))  ) 

8  •••••••••••••••••••••••Retrieving  similar  <rid  pUn*************************** 

9  RETRIEVE;  There  arc  2  possible  Complete  Msiches.  They  are.. 

10  (({<PUn::6BS>)  ((L  A)  (N  E)  (M  D)  (O  C)  (P  B))) 

1 1  ({ <PUn::6BS>)  ((L  B)  (N  F)  (M  E)  (O  D)  (P  C)))) 

12  •  •  • 

13  •••••••plaN-KERNEL-BASEIM)RDERING 

14  The  Plan  Choices  ranked  best  by  the  Plan-kernel  based  retrieval  Process  are 

15  a({<Pl«n::6BS>)  ((L  A)  (N  E)  (M  D)  (O  O  (P  B))))(18)) 

16  Choosing 

17  (({<PUn::6BS>)  ((L  A)  (N  E)  (M  D)  (O  C)  (P  B)))J{18) 

18  to  be  reused  to  solve  the  current  problem 

19  Copying  and  Loading  plan  into  memory 

20  using  the  following  pirn 

21  Plan  Name:  6BS 
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22  Gotli:  ((ON  B  O  (ON  C  D)  (ON  D  E)  (ON  E  F)  (ON  A  B)) 

23  Imtuil  Su:^:  ((BLOCK  D)  (Bli3CK  B)  (BLOCK  A>  (CLEARTOP  A) 

24  (BLOCK  O  (CIXARTOP  D)  (CLEARTOP  C)  (QJ^ARTOP  B) 

25  (ON  D  TABLE)  (ON  C  TABLE)  (ON  B  TABLE)  (ON  A  TABLE) 

26  (BLOCK  F)  mLOCK  E)  (CXEAKTOP  F)  (CLEARTOP  E) 

27  (ON  E  TABLE)) 

2S  Plin  Kcrr.d:  «<PLANKEKN1£L  10733054> 

29  The  p!*n  is... 

30  . . . 

31  7:  J’RIN!rn\^  (PUT-BLOCK-ON-BLOCK-ACnON  E  E)  tPren<x*tJ:(21  22)]  liuccnodc*:  (6  1)) 

32 

33  6:  iPRD.mrV'B  (PUT- BLOCK-ON- BLOCK* ACTION  D  E)  (Prenodea:(18  19  7)]  (Succnoda:  (5  1)J 

34 

35  5:  iPRIMmVE  (PUT- B LOCK- ON-BL<XK- ACTION  C  D)  (P«ro<ks:(15  16  6)]  [Succnode*:  (4  1)) 

36 

37  4:  JJRIMmV'E  (PUT-BLOCK -ON-BLOCK- ACTION  B  C)  (Prcnodcs:(12  13  5)]  [Succnod«;  (3  1)] 

38 

39  3:  J^RIXtrnVE  (PUT-BLOCK-ON-BLOCK-ACnON  A  B)  [Pnaiod«:(9  10  4))  (Succnoda:  (1)} 

40  . . 

41  The  mapping  if  {A-*L  E->N  D->M  C-+0  B*-*P  ) 


Next,  the  6BS  plan  is  interpreted  in  the  5BP  problem  situation  with  the  chosen  mapping. 
The  interpretation  process,  apart  from  marking  various  facts  as  in  and  out,  finds  that  one  of 
the  goals  of  the  6BS  problem,  On{N ,F),  is  unnecessary  for  solving  5BP  problem  (line  57). 
Figure  A.2  shows  the  HTN  of  the  6BS  plan  after  the  interpretation  process. 


42  ••••••••••••••••••  ••••••••••••••••••• 

43  Mapping  the  retrieved  plan  into  the  current  problem 

44  The  mapping  used  is:  [A-^L  E-">N  D--+M  C-+0  B-*P  ] 

45  INTERPRET:  adding  fact  (ON  O  P)  to  the  initial  aute 

46  interpret:  adding  faa  (PYRAMID  L)  to  the  initial  sute 

47  INTERPRET:  adding  fact  (ON  M  N)  to  the  initial  lUte 

48  INTERPRET:  Madcing  the  fact  (BLOCK  L)  in  init-autc  rout 

49  INTERPRET:  Miridng  the  fact  (CLEARTOP  L)  in  inii-sute  rout 

50  INTERPRET:  Marking  the  fact  (CLEARTOP  P)  in  init-sute  rout 

51  INTERPRET:  Marking  the  fact  (ON  M  TABLE)  in  init-autc  rout 

52  INTERPRET;  Marking  the  fact  (ON  O  TABLE)  in  init-aute  rout 

53  INTERPRET:  Marking  the  fact  (BLOCK  F)  in  mii-sutc  rout 

54  INTERPRET:  Marking  the  faa  (CLEARTOP  F)  in  init-autc  rout 

55  INTERPRET:  Marking  the  faa  (CXEARTOP  hO  in  init-aute  rout 

56  INTERPRET;  Marking  the  faa  (ON  N  TABLE)  in  init-aute  rout 

57  INTERPRET:  Marking  the  goal  (ON  N  F)  in  g^-aute  numeceisary 

58  INTERPRETadon  ia  over 


Next,  PRIAR  starts  the  annotation  verification  process;  figure  A.3  shows  the  HTN  after  this 
process.  During  the  annotation  verification  process,  PRIAR  first  considers  the  unnecessary  vali¬ 
dation  supporting  the  unnecessary  goal  On{N  (lines  59-65).  The  appropriate  repair  action 
is  to  recursively  remove  the  parts  of  the  plan  whose  sole  puipose  is  to  achieve  this  validation. 
In  this  case,  PRIAR  finds  that  the  sub-reduction  below  the  intermediate  level  node 
NDOllO:  On{N JF)  (the  node  with  a  single  asterisk  in  Figure  A.2)  will  have  to  be  removed 
from  the  plan  to  take  care  of  this  unnecessary  validation.  Consequently,  the  annotation  verified 
plan,  shown  in  figure  A.3,  does  not  contain  any  nodes  of  this  sub-reduction. 


59  Annouoon  Vaifictiion*************** 

60  ANNOrr-VERIFY:  Suit 

61  ANNOT- VERIFY:  PtDCessing  unnecetury  goals  (if  any) 

62  The  goal  (ON  NF)  is  UNNECESSARY 

^  Icnovt  UsotoMary  Gcal:  Pnining  the  seduction  below  the  node 

64  {^:J^D0110>[<X)AL(ONN  F)] ...) 

65  To  lake  care  of  this  unneceuary  goal. 
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Figure  A.2.  6BS  plan  after  interpretation 


Next,  the  annotation  verification  checks  for  any  p -phantom  validations.  It  finds  that  the 
validation  supporting  the  goal  On(MJ^)  is  a  p -phantom  validation  since  On(MJ^)  was 
achieved  through  task  reduction  in  the  6BS  plan,  while  it  is  now  tnie  in  the  initial  state  of  the 
new  problem  situation.  PRIAR  uses  the  planner’s  goal  achievement  procedures  to  check  whether 
OniMJ^)  can  now  be  established  from  the  initial  state.  As  this  check  is  successful,  PRIAR 
decides  to  shorten  the  plan  by  pruning  the  validation  that  is  currently  supporting  the  goal 
On(M  ,iV),  and  to  support  On(MJ^)  by  the  new  fact  from  the  initial  state.  This  pruning  will 
remove  the  sub-reduction  below  the  node  ND0109:  On{MJ^)  (see  the  double-asterisked  node 
in  Figure  A.2)  from  the  interpreted  plan.  Consequently,  the  annotation  verified  plan,  shown  in 
Figure  A.3,  does  not  contain  any  nodes  of  this  sub-reductioa 
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Figure  A  J.  6BS  plan  after  annotation  verification 

66  ANNOT^VERCFY:  Processing  p-phsnicxn  vtlidations  (if  tny) 

67  The  goal  (ON  M  N")  is  fupponed  by  a  p-phantom  validation 

68  Checking  to  tee  if  it  can  be  phintcmiied 

69  Oicck>p>Phantoin-Va!tdath>i);  the  condition  (ON  M  N) 

70  can  be  established  from  new  initial  state!!! 

71  CWck'p-PhaBtont-ValkUtloB:  Pruning  the  other  contributor 

72  {<6;J^268>(PRIMrnVE(Pl7r-BLOCX-ON-BLOCK*ACnON  M  N)]  ...) 

73  fitro  the  HTN 

74  Pruning  the  reduction  below  the  node 

75  (<6;  J®0109>(KX)AL(ON  M  N)1 ...  J 

76  To  take  care  of  this  p-phantons  validation 


After  taking  care  of  unnecessary  and  p -phantom  validations,  the  annotation  verification 
procedure  finds  that  the  validation  supporting  the  filter  condition  Block(L)  is  failing,  because  L 
is  a  Pyramid  in  the  new  problem  situatioa  The  appropriate  repair  action  is  to  replace  the  sub- 
reduction  below  the  node  which  first  posted  that  filter  condition.  In  this  case,  PRIAR  finds  that 
the  node  ND0106:  On{LJ*),  which  is  an  ancestor  of  the  rxxle  with  the  failing  filter  condition 
validation,  first  posted  the  filter  condition  Block(L)  into  the  plan.  So  it  decides  to  replace  the 
sub-reduction  below  this  node.  Consequently,  the  annotation  verified  plan  in  Hgure  A.3  con¬ 
tains  a  refit  task  REFIT-TASK0004:  Achieve [On(LJ*)]  in  place  of  the  replaced  sub-reduction. 

77  ANNOT* VERIFY:  Processing  ewn  gods  (if  iny) 

78  aN  NOT* VERIFY:  Looking  for  failed  vtlidatiant.. 

79  The  FILTER  (ruse-whea)  condition  (BLOCX  L)  at  node 

80  {<3:dVI)0232>( J>RIMrnVE(Pin*-BLCX3C  ON.BLCXX.ACnON  L  P)i  ..) 

81  is  failing  because  of  »3ut  fact  (BLO(3C  L)  in  <INrr-STATE> 

82 

83  REFTT-FILTER-COND^PAILURE:  Adding  a  idiMaik 

84  {<REFrr-TASK0004>(ilEPLACE-REDUCnON(ON  L  P)]  -.) 

85  to  reproduce  the  node 

86  (<3::Nr)0106>[.<X)AL(ON  L  P))...) 
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REKTT-^TLTTS -CON'D- FA ILirRF-  Rcrnoving  ihc  rcpltcwi  roduciion  from  the  plAn 


The  annotation  verification  procedure  goes  on  to  find  a  second  failing  filter  condition 
validation  and  a  failing  phantom  condition  validation  (lines  88-105).  It  repairs  them  by  adding 
a  second  replace  reduction  refit  task  and  a  dephantomize  refit  task  to  the  annotation-verified 
plan.  Figure  A. 3  shows  the  partially  reduced  HTN  after  the  annotation-verification  process. 
This  is  then  sent  to  the  planner  for  refitting. 


88  The  FE-TER  (:use-whcn)  condition  (ON  OTARLE) 

89  at  node  {<5::NXW231>(;rRIS1TnVECPUT.BLOCX<>N*BtjOCX.ACmON  O  M)] it  fultng 

90  because  of  :oui  fact  (ON  O  TABLE)  in  <lNTr*STATE> 

91  ROTT-FlLTai  COMVFAlLUli:;  Adding  a  refit-tuk 

92  {<J^EFTTTASK0002>(;REPLACE-REDU(mON(PlJT*BLOCK-(^-BLOCK  O  M)J ...  ) 

93  to  re*reduce  the  node 

94  (<5:JSTX)176>[:ACnON(PlJT.BLOCK-ON-BLOCK  O  M)] 

95  REFn'-nLTO-COM>-FAlLURE:  Removing  the  replaced  reduction  from  the  plan 

96  The  :PRECOND  condition  (CLEARTOP  P)  at  node 

97  {<4:;ND0106>  ( J>RlMrriVE(PUr*BLOCK-ON*BLOCX-ACnON  P  O)) 

98  is  failing  because  of  :out  fact  (CLEARTOP  P)  in  <INIT-STATE> 

99 

100  DEPIUNTOMIZE-GOAL:  Adding  refit  Usk 

101  {<REnT.TASK0006>[:DEPHANTOMIZE(CLEARTOP  P)J... ) 

102  in  the  ^aoe  of  the  phantom  goal 

103  {<12:JSXK)154>(:GOAL(CL£ARTOP  P)) ...) 

104 

IDS  annot-verify:  Entering  lefit-uaks  into  the  plannen  TASK-QUEUE  in  correct  order 

106  Entering  (<REnT-TASKOO(M>(:REPLACE-REDUCnON(ON  L  P))...) 

lOr?  Entering  { <REFrTTASK0002>[:REPLACE-REDUCnON  (PUT-BLOCK-ON-BLOCK  O  M)]...) 

108  Entering  {<REFIT-TASK0006>(£)EPUANrOMIZE(CLEARTOP  P)J...) 

109  ANNOT-VERIFY:  END 


The  planner  starts  by  reducing  the  replace-reduction  refit  task  corresponding  to  OndJ*) 
Qines  111-129).  Since  Z.  is  a  pyramid,  the  planner  finds  that  the  only  appropriate  schema 
instance  for  reducing  this  refit  task  is  MAKE-PYRAMID-0N-BL0CK(L,/’).  Next,  since  the  refit 
task  is  a  replace-reduction  refit  task,  during  installation,  PRIAR  finds  that  the  e -precondition  of 
the  refit  task  that  was  supporting  the  condition  Clear {L),  is  no  longer  required  by  the  new 
schema  instance  (the  reason  being  that  L,  which  is  a  pyramid,  is  always  clear).  So  the  e- 
precondition  is  pnined  from  the  HTN.  After  this,  the  planner  goes  on  to  reduce  the  refit  task 
with  the  chosen  schema.  The  other  two  refit  tasks  are  also  reduced  in  turn  by  a  similar  process 
Gines  135-141). 

Figure  A.4  shows  the  result  of  refitting,  which  is  a  completely  reduced  HTN  for  solving 
the  5BP  problem.  The  shaded  nodes  represent  the  parts  of  the  6BS  plan  that  remain  applicable 
to  the  5BP  problem,  and  the  white  nodes  represent  the  reductions  of  refit  tasks.  There  is  no 
separate  sub-plan  for  achieving  the  goal  Ort(Af  JV)  in  this  HTN  since  this  is  made  tnie  from  the 
initial  state  of  SBP  problem. 
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110  G<incT*uv-c  pijnr.cr************************* 

111  n^ssrn:  Ctpand-ng  uik  Achieve  f(ON  L  fO] 

1 12  PI-ASNST:  The  fcherru  choices  to  rrducc  the  refil  lisk  sre: 

in  ({SCU0021)  HAKH-PYRANtrn-ON  m.OCKOlMOOIS  :CONL  P) 

J  !■»  BY  {<1  .:Nr)OC:a>[j\CTTONa’bT*PY'RA>fID^OVBLOCK  L  P))-  •) 

1 1 5  TYc  choser  schcmi  is  : 

116  {sar.>02i) 

117  NlAKr  PYRAMID  ON-BLOCK0014001S;  (ON*  L  P) 

118  Expimion: 

119  0  {<0.:NT>0019:>[:GOALCaj:ARTOr  P)]) 

120  1  {<l;:NT>a'i2()>[.ACTION(PLT-P^'RA>ttD<)N-BLOCKL  P))) 

121  Condibons; 

122  «SC5125»  lPRECOND  (CLEARTOP  P)  :*t  1  from  (0) 

1 23  «SC5 1 26»  tUSEA^lIEN  (PYRAMID  L)  ;*i  0  from  (-24) 

124  «SC5127»  :i;SE- WIEN  (BLOCK  P):«il  frt*Tt  (-24) 


126  lR5t>ll  Chote*:  InsuUin^  ihe  fchemi  ({5010021) 

127  MAKE-PYRAMir>.ON-BLOCK00140018::(ON  L  P)  BY 

12S  (<1  ;uNIXKJ20>[ACTION(Pirr.PYRA.VlID-ON-BLOCK  L  P)1 

129  to  Re-rcducc  the  uik  ({cREFTT  TASK00O4>[:REPIJ^CE-REDUCnON(ON  L  P)])) 

130  The  €  -precondition  ((XEARTOP  L)  of  the  t»xk 

131  {{<REnT-TASKOOCW>[:REPlACE-REDUCnON(ON  L  P))}) 

132  is  no*  required  by  the  choser.  ichem* 

133 

134  So,  pruning  the  vslidation  corresponding  to  this  nemdition 
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Figure  A.4.  Result  of  refitting  6BS  plan  to  5BP  problem 
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136  PLANNT,*:  F*p«nding  Re/it  unk  Achirve  [{PUT  BFtXTK'ON  BIXXTK  O  Nf)) 

137  rL4NVF,T!:  Tltc  itcKcm*  ch<.>ii.-T*  lo  rr<}ix‘r'  ihc  rcF.t  udi  trc 

ns  ((SCI  10777)  pirr-iu,(xx-c\  BLocKoo72ooz^  inn  ni  ock-on  p^.ock  o  m)  by 

139  {<d>;;NT>«7:4»>(-PRJMrmT(Pin'-nLCX3: -ON  BLOCK-ACTION  O  Ni))} 

140  riANSrX;  Expanding  Rtfij  utk  Ach^rv-c  ((QZARTOP  F)) 

141  Th«  rr.ru-usk  u  rilANT0N?I7J:D  »nih  in  effect  of  ihc  tiodefs) 

142  ((<5..VtXX^26>(J’^U^^rmT:(^LT■BUXX-O^^nL0CK-ACTl0N  O  M)l)) 

143  ••••The  riinniitg  is  0\^R 

144  The  pltn  is... 

. . . . . . . 

146 

147  5:  :PRIAnTIVE  (PLT-BLOCK-ON-BLOCK-ACnON  O  N!)  (m  .  -’es  (6  15  16))  (Succnoda:  (3  1  4)) 

145 

149  4:  J’mtmVE  (PLT  BLOCK-ON-BLOCK-ACnON  P  O)  [Prenode»:<l2  5  13))  JSuccnoda:  (23  1)] 

150 

151  3:  PRIMmVE  (ITJT-PYRAVtKVON  BLOCK-ACnON  L  P)  ,ftmode*:(23  0  5)j  {Soccnodci:  (1)) 


152  •••••••••••GOAL 

153  «SC005i»  ™=COND  (ON  O  M)  :*i  1  (5) 

154  «SC0061»  TOICOND  (ON  P  O)  :«i  1  iwtn  (4) 

155  «SCOOeCt»  JHECOND  (ON  L  P) ;«  1  from  (3) 

156  «SC0059»  JTiECOND  (ON  M  N)  :*l  I  :&xxn  (0) 
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4^ 


Appendix  B.  The  Blochs  World  Domain  Specification 


(self  ♦aut(X'ond*  0 

: ; :Aiiionuitica!Iy  fill  in  sub- goals  as  preconditions  of  main  goal  steps 

(opschema  make -pvTam  id-on-block 
:lodo  (on  ?x  ?y) 

:cxpansion  ((stcpl  :goaI  (clcanop  ?y)) 

(step2  laction  (pul-pyTamid-on-block  ?x  ?y)) ) 
rordcrings  ((stcpl  ->  siep2)) 
rconditions  ((:fiUcr  (pyramid  ?x)  :at  stepl) 

(:fi!ter  (block  ?y)  :al  stcp2)) 
teffects  ((slcp2  :dclctc  (cicartop  ?y)) 

(sicp2  :assert  (on  ?x  ?y))) 
rvariables  (?x  ?y)) 

(opschema  make-p>Tam id-on- table 
:todo  (on  ?x  table) 

rexpansion  ((siepl  :action  (put-p>Tam id-on-table  ?x  ?y))) 
rconditions  ((ifilter  (pyramid  ?x)  rat  stcpl)) 
reffects  ((stepl  rassert  (on  ?x  table))) 

: variables  (?x  ?y)) 

(opschema  makc-block-on -block 
rtodo  (on  ?x  ?y) 

: expansion  ((stepl  rgoaJ  (cleartop  ?x)) 

(siep2  rgoaJ  (cleartop  ?y)) 

(step3  raction  (put-block-on-block  ?x  ?y))) 
rorderings  ((stcpl  step3)  (  stcp2  slcp3)) 

rconditions  ((rfilier  (block  ?x)  rat  stepl) 

(rfilter  (block  ?y)  rat  sicp2)) 
reffects  ((sicp3  rdeletc  (cleartop  ?y)) 

(step3  rassen  (on  ?x  ?y))) 
rvariables  (?x  ?y)) 

(opschema  makc-block-on-table 
rtodo  (on  ?x  table) 

rexpansion  ((stcpl  rgoal  (cleartop  ?x)) 

(step2  raction  (put-block-on-table  ?x  table))) 
rconditions  ((rfilter  (block  ?x)  rat  stepl)) 
rorderings  ( (stepl  siep2)) 

reflects  ((step2  rassen  (on  ?x  table))) 
rvariables  (?x  ?y)) 


(opschema  make-clear-tabIc 
rtodo  (cleartop  ?x) 
rexpansion  ((stepl  rgoal  (cleartop  ?y)) 

(step2  raction  (pul-block-on-table  ?y  table))) 
rorderings  ((stepl  siep2)) 
rconditions  ((rfilter  (block  ?x)  rat  stepl) 

(rfilter  (block  ?y)  rat  step2) 

(rfilter  (on  ?y  ?x)  rat  siep2) ) 
reffects  ((siep2  rassert  (cleartop  ?x)) 

(stcp2  rassen  (on  ?y  table))) 


: variables  (?x  ?y)) 


(opschema  makeclear-block 
:todo  (cleartop  ?x) 

;expansion  ((siepl  :goaI  (cleartop  ?y)) 

(step2  :action  (put-block-on-block  ?y  ?z)) ) 
:orderings  ((stepl  step2)) 

rconditions  ((rfilter  (block  ?x)  :at  stepl) 

(:filter  (block  ?y)  :ai  stepl) 

(ifilier  (block  ?z)  :ai  stepl) 

(:filter  (on  ?y  ?x)  :at  step2) 

(:  filter  (cleartop  ?z)  :al  step2) 

(: filter  (not  (equal  ?z  ?y))  rat  stepl) 

(rfilter  (not  (equal  ?x  ?z))  rat  stepl) ) 

:effects  ((step2  rasscrt  (cleartop  ?x)) 

(step2  rassert  (on  ?y  ?z)) 

(step2  rdelete  (cleartop  ?z)) ) 

:variab!es  (?x  ?y  ?z)) 

(actschema  put-block-on-block 

:todo  (put-block-on-block  ?x  ?y) 

:expansion  ((stepl  rprimitive  (pui-block-on-block-action  ?x  ?y))) 
:conditions  ((rfilter  (block  ?x)  rat  stepl) 

(rfilter  (block  ?y)  rat  stepl) 

(rfilter  (cleartop  ?x)  rat  stepl) 

(rfilter  (cleartop  ?y  )  rat  stepl) 

(rfilter  (on  ?x  ?z)  rat  stepl) ) 

:effects  ((stepl  rassert  (on  ?x  ?y)) 

(stepl  rassert  (cleartop  ?z)) 

(stepl  rdelete  (cleartop  ?y)) 

(stepl  rdelete  (on  ?x  ?z)) ) 

:variables  (?x  ?y  ?z) 

) 

(actschema  put-pyramid-on-block 

:todo  (put-pyramid-on-block  ?x  ?y) 

:expansion  ((stepl  rprimitive  (put-pyramid-on-block-action  ?x  ?y))) 
:conditions  ((rfilter  (pyramid  ?x)  rat  stepl) 

(rfilter  (block  ?y)  rat  stepl) 

(rfilter  (cleartop  ?y  )  rat  stepl) 

(rfilter  (on  ?x  ?z)  rat  stepl) ) 

:elTects  ((stepl  rassert  (on  ?x  ?y)) 

(stepl  rassert  (cleanop  ?z)) 

(stepl  rdelete  (cleartop  ?y)) 

(stepl  rdelete  (on  ?x  ?z)) ) 

:variables  (?x  ?y  ?z)) 

(actschema  put-block-on-tahle 

:todo  (put-block-on-table  ?x  table) 

rexpansion  ((stepl  rprimitive  (put-block-on-table-aciion  ?x  table))) 
rconditions  ((rfilter  (block  ?x)  rat  stepl) 

(rfilter  (cleartop  ?x)  rat  stepl) 

(rfilter  (on  ?x  ?z)  rat  stepl) ) 
reffects  ((stepl  rassert  (on  ?x  table)) 

(stepl  rassert  (cleartop  ?z)) 

(stepl  rdelete  (on  ?x  ?z)) ) 
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:variables  (?x  ?z)) 


(actschema  put-pyramid-on-table 

:todo  (put-pyramid'On-table  ?x  table) 

:expansion  ((stcpl  rprimitive  (put-pyramid-on-table-action  ?x  table))) 
:conditions  ((rfilter  (pyramid  ?x)  :at  stepl) 

(: filter  (on  ?x  ?z)  :at  stepl) ) 
reffects  ((stepl  rassert  (on  ?x  table)) 

(stepl  rasserl  (cleartop  ?z)) 

(stepl  rdeleie  (on  ?x  ?z))) 

:variab!es  (?x  ?z)) 

(domain-axioms 
(4~  (cleartop  table) 
t) 

;;(cleartop  table)  is  always  derivable 
(<r-  (not  (cleartop  ?x)) 

(on  ?y  ?x))  ;;if  ?y  is  on  ?x  then  ?x  cannot  be  clear 
(<-  (not  (on  ?other  ?x)) 

(and  (block  ?x)(on  ?z  ?x))) 

;;if  ?x  is  a  block  and  ?z  is  on  top  of  ?x,  nothing  else  is  on  its  top 
(<-  (not  (on  ?z  ?other)) 

(on  ?z  ?x)) 

::if  ?z  is  on  ?x  it  is  not  on  any  other  block 

(f~  (not  (on  ?x  ?y)) 

(pyramid  ?y)) 

;;nothing  can  be  on  the  top  of  a  pyramid 
(<-  (equal  ?x  ?x) 

1) 

;;equality  axiom) 

(closcd-world-predicate  ’equal  :set  t) 

;;record  that  equality  is  a  closed-world  predicate 
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